Sign in
Microsoft.com
 
Microsoft
 
 
 
Microsoft >
> 
> 
> 
802.11b code transmit failure

Unanswered 802.11b code transmit failure

  • Tuesday, November 30, 2010 3:56 PM
     
     
    Sign In to Vote
    0

    I downloaded the Sora SDK and 802.11b code, compiled a checked x86 build, and started the driver with a static IP, but can't ping to/from another computer with the same SSID.  I then connected via a serial cable to kernel debugging output to try to see what was going on, the result is below.

    Should the BSSID registry key be set to a 12 hex digit string equal to the ad hoc BSSID currently in use, or should it be set to a free-form ASCII string equal to the SSID currently in use?

    Is anyone familiar with the lines "[Error] f10: ffffffff" or "[Error] BufPa=00871000,Size=00008100,watchdog=cdcdcdcd,SV=1,MF=0,R=000c"?  They are not coming from the sora code as far as I can tell.

    "[RX][Warning] BB11BRx fail:80050103" seems to just be the PHY triggering on receive, but not finding an SFD, which is bound to happen sometimes, right?

    "[RX][Warning] BB11BRx fail:80050100" seems to be some kind of energy-detection related failure, also non-critical.

    "[TX][Error] I can't tx it out because transfer fail, make it TXDone to complete" is bothering me - why would this happen?  I'm guessing that no packets are being sent from Sora as a result.

    Debug log:

    [MAC_CS] channel clean, goto tx
    [Error] f10: ffffffff
    [MAC_CS][Warning] LAG
    [Error] f14: ffffffff
    [MAC_CS][Warning] LAG
    [Error] f18: ffffffff
    [MAC_CS][Warning] LAG
    [Error] f1c: ffffffff
    [MAC_CS][Warning] LAG
    [Error] f20: ffffffff
    [RX][Warning] BB11BRx fail:80050100
    [Error] f24: ffffffff
    [Error] BufPa=00871000,Size=00008100,watchdog=cdcdcdcd,SV=1,MF=0,R=000c
    [RX][Warning] BB11BRx fail:80050103
    [Error] 80: ffffffff
    [MAC_CS][Warning] LAG
    [Error] 84: ffffffff
    [MAC_CS][Warning] LAG
    [Error] 88: ffffffff
    [RX][Warning] BB11BRx fail:80050100
    [Error] 8c: ffffffff
    [MAC_CS] channel clean, goto tx
    [Error] 90: ffffffff
    [TX][Error] I can't tx it out because transfer fail, make it TXDone to complete
    [Error] 94: ffffffff
    [MAC_CS][Warning] LAG
    [Error] 98: ffffffff
    [MAC_CS][Warning] LAG

     

     

     

     

All Replies

  • Wednesday, December 01, 2010 9:42 AM
    Owner
     
     
    Sign In to Vote
    0

    Hi

    The BSSIC key should be equal to BSSID of the network.

    From the error log, looks your CPU is too slow. What type of CPU do you use?

    - Kun

     
  • Wednesday, December 01, 2010 10:21 AM
     
     
    Sign In to Vote
    0

    Intel Xeon X5560 @ 2.80 GHz running Windows XP (4 cores).  My Sora driver is a checked build, and serial debugging @ 115200 baud is turned on, so this might slow things down, but things don't work with the free build and serial debugging turned off.

    What about the "[TX][Error] I can't tx it out because transfer fail, make it TXDone to complete" -- could this indicate a hardware failure?

    Thanks.

     
  • Wednesday, December 01, 2010 1:01 PM
    Owner
     
     
    Sign In to Vote
    0

    Hi,

    You can not use chk build for real-time test. It is way too slow.

    Yes. The error message says the transfer operation fails. Can you first make sure the hardware work well?

    You can try to make a dump and check if there are anything interesting there.

    Best,

    - Kun

     
  • Wednesday, December 01, 2010 3:53 PM
     
     
    Sign In to Vote
    0

    Okay - I loaded the HW test Ethernet Adapter with console debugging turned off, and ran:

    dut start

    dut transfer --file c:\SoraSDK\bin\TxSamples11b\1long44.mf.bin

    dut status (showed one signal cached)

    dut tx --sid 0x0 --value 10000

    --> Ret: 0x000000, and using WiSpy, I see an 802.11b signal going out over the air.  So no problems transmitting here.

    dut rx

    --> Ret 0x0000

    dut dump

    --> Ret 0x000

    dut dump --file c:\dump.bin

    --> Ret 0x00

    but, I can't find any dump file created.

    Do I have the dut syntax wrong for receive?  I'd like to test the receive path so I know that it's not a factor getting the free build of the Sora driver working.

    Thanks.

     
  • Thursday, December 02, 2010 8:53 AM
     
     
    Sign In to Vote
    0

    Update - with dut I can transmit TxSamples11b\2long44.mf.bin, and receive it successfully with tcpdump:

    16:42:16.481624 2948738539318852572us tsft short preamble 2.0 Mb/s 2422 MHz (0x0480) -62dB signal -96dB noise antenna 2 34dB signal 0us IP (tos 0x0, ttl 128, id 46376, offset 0, flags [none], proto UDP (17), length 78) 192.168.2.6.netbios-ns > 192.168.2.255.netbios-ns: [|SMB]

    Unfortunately still the dot11b miniport driver still doesn't work; here I've used the checked build and DbgPrint to trace the failure down to src\driver\mac\sdr_mac_send.c in the SdrMacSendThread's call to SORA_HW_TX_TRANSFER.  This call fails.  SORA_HW_TX_TRANSFER as far as I can tell is implemented in a kernel library ksora.lib, the source code of which is not provided, so I'm unable to trace deeper into SORA_HW_TX_TRANSFER to debug the problem.

    If I try a free build of the driver with kernel debugging turned off, same symptom.

    Could this still be a hardware bug, given that dut is working as described above?

    Thanks.

     
  • Thursday, December 02, 2010 1:18 PM
    Owner
     
     
    Sign In to Vote
    0

    You may first try to use dut/hwtest to get some dump file before you go with miniport driver.

    After dut rx, you shoud set rx gain.

    Try the following sequence,

    > dut rxpa --value 0x2000

    > dut rxgain --value 0x1800

    > dut dump

    You may find a dmp file at c:\

    (btw, there is no such usage "dut dump --file xxx" :)

     
  • Friday, December 03, 2010 12:06 PM
     
     
    Sign In to Vote
    0

    dut dump fails on my Sora - there is no "dmp" file in c:\ as shown below.  Is this a hardware problem?

    C:\>dut stop
    Ret:0x00000000
    C:\>dut start
    Ret:0x00000000
    C:\>dut rxpa --value 0x2000
    Ret: 0x00000000
    C:\>dut rxgain --value 0x1800
    Ret: 0x00000000
    C:\>dut dump
    Ret:0x00000000
    C:\>dir
     Volume in drive C has no label.
     Volume Serial Number is 1833-0118

     Directory of C:\

    11/20/2010  04:49 PM                 0 AUTOEXEC.BAT
    11/24/2010  07:31 PM    <DIR>          bcbde3a7aa521bfab7a250b737
    11/29/2010  06:30 PM               369 boot.ini
    11/20/2010  04:49 PM                 0 CONFIG.SYS
    11/24/2010  10:14 AM    <DIR>          cygwin
    11/20/2010  04:56 PM    <DIR>          Documents and Settings
    11/20/2010  04:39 PM    <DIR>          nView
    11/30/2010  12:22 PM    <DIR>          Program Files
    12/02/2010  11:37 AM    <DIR>          SoraSDK
    11/23/2010  05:27 PM    <DIR>          WinDDK
    12/02/2010  05:47 PM    <DIR>          WINDOWS
                   3 File(s)            369 bytes
                   8 Dir(s)  191,248,084,992 bytes free

     
  • Friday, December 03, 2010 1:25 PM
    Owner
     
     
    Sign In to Vote
    0

    in your operation sequence, you missed dut rx.

    Please try following sequence.

    1. Please check the RCB PCIE driver is correctly installed.

    2. Please check the hwtest driver is correctly installed.

    3. Reboot and open a command window and change dir to dut file

    4. type in following commands

    dut start

    dut rx

    dut rxpa --value 0x2000
    dut rxgain --value 0x1800
    dut dump

    Then, check c:\ to see any .dmp file exists.

    If still fail, there may be compatibility issue. Please send us your detailed machine configuration, e.g. CPU type, motherboard chipset type, etc.

    You may find the machine setup that we use often at

    http://research.microsoft.com/en-us/projects/sora/academickit.aspx

    Thanks,

    - Kun

     
  • Friday, December 03, 2010 2:22 PM
     
     
    Sign In to Vote
    0

    Thanks for your help.  However, still no dump file :-(

    Sora Radio Manager 250MHZ 4X for PCIE board, Driver Date 5/20/2010, Driver Version 6.0.6001.18000 installed, and no errors/warnings.

    Microsoft Sora HW Test Ethernet Adapter installed, no warnings, no errors.

    Rebooted.

    Drivers still OK.

    Then:
    C:\SoraSDK\bin>dut start
    Ret:0x00000000

    C:\SoraSDK\bin>dut rx
    Ret:0x00000000

    C:\SoraSDK\bin>dut rxpa --value 0x2000
    Ret: 0x00000000

    C:\SoraSDK\bin>dut rxgain --value 0x1800
    Ret: 0x00000000

    C:\SoraSDK\bin>dut dump
    Ret:0x00000000

    C:\SoraSDK\bin>dir \
     Volume in drive C has no label.
     Volume Serial Number is 1833-0118

     Directory of C:\

    11/20/2010  04:49 PM                 0 AUTOEXEC.BAT
    11/24/2010  07:31 PM    <DIR>          bcbde3a7aa521bfab7a250b737
    11/29/2010  06:30 PM               369 boot.ini
    11/20/2010  04:49 PM                 0 CONFIG.SYS
    11/24/2010  10:14 AM    <DIR>          cygwin
    11/20/2010  04:56 PM    <DIR>          Documents and Settings
    11/20/2010  04:39 PM    <DIR>          nView
    11/30/2010  12:22 PM    <DIR>          Program Files
    12/02/2010  11:37 AM    <DIR>          SoraSDK
    11/23/2010  05:27 PM    <DIR>          WinDDK
    12/02/2010  05:47 PM    <DIR>          WINDOWS
                   3 File(s)            369 bytes
                   8 Dir(s)  191,243,833,344 bytes free

    From msinfo32.exe:
    System Model    Precision WorkStation T7500
    Intel Xeon X5560 @ 2.80 GHz
    Processor    x86 Family 6 Model 26 Stepping 5 GenuineIntel ~2793 Mhz
    BIOS Version/Date    Dell Inc. A07, 10/8/2010
    OS Name    Microsoft Windows XP Professional
    Version    5.1.2600 Service Pack 3 Build 2600
    IRQ 48    Sora Radio Manager 250MHZ 4X for PCIE board    OK
    Total Physical Memory    6,144.00 MB
    Available Physical Memory    3.03 GB
    0xDFEFC000-0xDFEFFFFF    Sora Radio Manager 250MHZ 4X for PCIE board    OK

    From Intel chipset identification utility:
    Intel® 82801JIR Intel® I/O Controller Hub (ICH10R)

    From device manager:
    Intel 5520/5500/X58 I/O Hub PCI Express Root
    Intel 82801 PCI bridge
    Intel ICH10 Family PCI Express Root

     
  • Thursday, December 09, 2010 4:51 PM
     
     
    Sign In to Vote
    0

    I'm planning on buying new PC hardware to fix this, but before I make that purchase I just want to try to verify that this is in fact an incompatibility with my chipset.

    Could you tell me:

    1) Does dut use SORA_HW_TX_TRANSFER to transmit with dut tx?  If so I believe that I don't have a HW incompatibility, so a problem elsewhere in the stack.

    2) If not, does dut use SORA_HW_FAST_TX to transmit from the cache? 

    Is it indicative of a hardware incompatibility for SORA_HW_TX_TRANSFER to fail but SORA_HW_FAST_TX to succeed?

    Many thanks.

     
  • Saturday, December 11, 2010 5:46 AM
    Moderator
     
     
    Sign In to Vote
    0

    Hi, xwy:

    I don't know why dut transfer fails while transfer in miniport driver succeeds, both of which are calling same API. From the debug output, there is a hardware error. Please wait for a while before purchasing new PC. thanks.

     

    Sen

     
  • Saturday, December 11, 2010 11:35 PM
    Moderator
     
     
    Sign In to Vote
    0

    Hi,

    If possible, could you find an i7-9xx CPU + x58 chipset platform and have a try. From your result, it looks there's hardware compatibility issue here. We have no experience on either the Dell Precision T7500 workstation or the x5560 CPU.

    Sorry for any inconvenience.

    Thanks

    -Jiansong