Re: Capturing FCS error frames using b43 driver
On Feb 17, 2009, at 11:54 PM, Michael Buesch wrote: Please read the code. There are lots of sanity checks in b43 and mac80211 that make it impossible to receive completely corrupted frames. I reconsidered this message because I too did some tests in capturing frames with proprietary firmware. As Bo said, we can capture corrupted frames with R351 but we can't with R410. The reason is that this firmware seems to not even check whether or not bit B43_MACCTL_KEEP_BAD is set so I believe no kernel patch could correct this problem, because it is on the firmware side. Cheers, -FG On Tuesday 17 February 2009 23:05:51 Bo Han wrote: Hi, I am interested in capturing FCS error frames using b43 driver. My hardware information is as follows. b43-phy9: Broadcom 4318 WLAN found b43-phy9 debug: Found PHY: Analog 3, Type 2, Revision 7 b43-phy9 debuf: Found Radio: Manuf 0x17f, Version 0x2050, Revision 8 I am using firmware version 410.2160 with linux kernel version 2.6.27.10. I told the firmware to keep the bad frames by setting ctl |= B43_MACCTL_KEEP_BAD just before b43_write32(dev, b43_MMIO_MACCTL, ctl) in b43_adjust_mode(...) in main.c. From b43_rx(...) in xmit.c, I can only see packets dropped because their rate_idx == -1. The length of all the dropped packets is 80 bytes and they look like the following: 8fae 0308 0b01 0085 1500 482c 50b3 0b01 0085 5fa0 1500 482c 50b3 0003 850b cdcc 1b00 1d00 b945 c0cd b905 630a 5e10 0101 0601 0b06 000b 07d6 bab9 addb 35fd 33e8 cd8f 8eaa 6f77 b9e8 However, there is still no packet received with macstat B43_RX_MAC_FCSERR. I also tried the 351 firmware for which I saw several FCS error frames in PIO mode. But the sniffing tools like Wireshark cannot get any packets. including the correct ones, when using that firmware. Am I missing something? Thanks, -Bo -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev --- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I need some help stabaizing b43 for a 4306
On Sunday 22 February 2009 21:45:44 John Mountcastle wrote: Michael, configuring a new kernel was a real blast from the past. I haven't done that in several years but I think I got it done. Funny thing, when I booted the debug kernel, the interface was rock solid for almost an hour, not one single error, then it went sour again. I switched on br43 debugging as you suggested, about half way through the capture. You can see the Tx-mit power messages start. About 60% into the capture I unloaded b43 (rmmod/insmod) and reloaded it in order to get the interface to come back up. I hope you can tell me something about what if anything this capture tells us? Or, the net step in debuggging b43-phy1 debug: Current TX power output: 14.75 dBm, Desired TX power output: 15.0 dBm b43-phy1 debug: Tuning TX-power to bbatt(5), rfatt(4), tx_control(0x30), tx_bias(0x00), tx_magn(0x00) The first thing I notice, of course, is the very low TX power output of 15dBm. Can you check iwconfig to check which TX power was selected? It should write something like this: wlan0 IEEE 802.11bg ESSID: Mode:Managed Frequency:2. GHz Access Point: X Bit Rate=XX Mb/s Tx-Power=20 dBm . So if there's a higher value than 15, please tell me so. If the value is 15 there, too. Try manually setting the TX power: iwconfig wlan0 txpower 20 This might be a bug in the card's PROM or possibly the code reading it. I also have a card where it incorrectly reads the TX power value (but it's 19dBm for me, so it doesn't matter that much for me...). Besides that, please tell me exactly at which point in the log messages it starts to break. That's essential information for me. Also, moving to latest b43 development code might help, too. It has improved TX power control code which might scale a bit better on your device. You can do so by downloading compat-wireless: http://wireless.kernel.org/en/users/Download -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: More data on open-source firmware crash
On Feb 22, 2009, at 8:10 PM, Larry Finger wrote: Francesco and Lorenzo, I modified my driver source to dump the firmware machine state whenever the b43_dma_handle_txstatus routine was called with an out-of-order cookie. With proprietary firmware, the test of a flood ping in one job and repeated tcpperf transmissions in a second ran for 10 hours without a single failure. With the open-source firmware it failed after about 2 hours. Below are the saved status data. Listed for each item are the cookie, the sequence number, and the skb length. The 0x84 length values come from the ping. All of the out-of-order items come from tcpperf - is it significant that they are from the longer set? Note that a number of cookie/sequence pairs are missing, namely: 2064/9C1, 2066/9C2, 2068/9C3, 206A/9C4, 206C/9C5, 2072/9C7, 2076/9C9, and 207A/9CB. Cookie 206E is missing, but the next sequence (9C6) was attached to cookie 2070. Larry, do you mind testing this firmware? It's not the solution, but can help us understanding if we should follow this way. Download at http://www.ing.unibs.it/~gringoli/fwtest.tar.gz Before using this firmware please recompile b43 changing these two definitions in b43.h #define B43_MARKER_ID_REG 52 #define B43_MARKER_LINE_REG 53 I coded the firmware so that it will raise a B43_DEBUGIRQ_MARKER with id 10, line 100 if the condition I'm thinking to is true. You will see (I hope) in dmesg. Thanks, bye -FG ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: I need some help stabaizing b43 for a 4306
Here is a little snippet of dmesg, just after I brought the link up. b43-phy0 debug: Current TX power output: 15.0 dBm, Desired TX power output: 15.0 dBm SFW2-OUT-ERROR IN= OUT=wlan0 SRC=192.168.0.197 DST=146.6.54.21 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=16037 DF PROTO=TCP SPT=57570 DPT=80 WINDOW=227 RES=0x00 ACK FIN URGP=0 OPT (0101080A002B6F416FD3DC29) SFW2-OUT-ERROR IN= OUT=wlan0 SRC=192.168.0.197 DST=146.137.96.7 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=10146 DF PROTO=TCP SPT=39841 DPT=80 WINDOW=589 RES=0x00 ACK FIN URGP=0 OPT (0101080A002B77F70FA3EE62) b43-phy0 debug: Current TX power output: 15.0 dBm, Desired TX power output: 15.0 dBm Here is iwconfig wlan0 mtcs...@sybill:~/Desktop sudo /usr/sbin/iwconfig wlan0 wlan0 IEEE 802.11bg ESSID:MBR-6d2 Mode:Managed Frequency:2.417 GHz Access Point: 00:30:44:02:76:D2 Bit Rate=1 Mb/s Tx-Power=27 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:7761-7465-7266-616C-6C30-3030-30 Security mode:open Power Management:off Link Quality=51/100 Signal level:-5 dBm Noise level=-17 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Note that while b43-phy0 debug says desired output is 15.0dBm, iwconfig says it's askigng for 27. Next I went about doing other things and when I saw the interface go down (NetworkManager) I shot off another dmesg. So, the very end of this message was within seconds of the interface going down. I may have to reinstalll frm scratch, I seem to have screwed up my kernel sources, I can't compile a new 'default' kernel. Let me know what you think of my little problem and what i should try next. Regards John Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.27.7-9-debug (ge...@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Sun Feb 22 16:55:19 EST 2009 PAT WC disabled due to known CPU erratum. BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3dee (usable) BIOS-e820: 3dee - 3deec000 (ACPI data) BIOS-e820: 3deec000 - 3df0 (ACPI NVS) BIOS-e820: 3df0 - 4000 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) DMI present. last_pfn = 0x3dee0 max_arch_pfn = 0x10 kernel direct mapping tables up to 3800 @ 7000-c000 RAMDISK: 37515000 - 37fefc04 ACPI: RSDP 000F6560, 0014 (r0 HP) ACPI: RSDT 3DEE674D, 0030 (r1 HP 3084 604 LTP0) ACPI: FACP 3DEEBED2, 0074 (r1 HP 3084 604 PTL50) ACPI: DSDT 3DEE6C96, 523C (r1 HP 3084 604 MSFT 10E) ACPI: FACS 3DEFCFC0, 0040 ACPI: BOOT 3DEEBFD8, 0028 (r1 HP 3084 604 LTP1) ACPI: SSDT 3DEE6B84, 010A (r1 HP 30841 INTL 20030224) ACPI: DMI detected: Hewlett-Packard 94MB HIGHMEM available. 896MB LOWMEM available. mapped low ram: 0 - 3800 low ram: - 3800 bootmap 9000 - 0001 (9 early reservations) == bootmem [00 - 003800] #0 [00 - 001000] BIOS data page == [00 - 001000] #1 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] #3 [10 - 6449dc]TEXT DATA BSS == [10 - 6449dc] #4 [0037515000 - 0037fefc04] RAMDISK == [0037515000 - 0037fefc04] #5 [645000 - 648000]INIT_PG_TABLE == [645000 - 648000] #6 [09f800 - 10]BIOS reserved == [09f800 - 10] #7 [007000 - 009000] PGTABLE == [007000 - 009000] #8 [009000 - 01] BOOTMAP == [009000 - 01] Zone PFN ranges: DMA 0x - 0x1000 Normal 0x1000 - 0x00038000 HighMem 0x00038000 - 0x0003dee0 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x - 0x009f 0: 0x0100 - 0x0003dee0 On node 0 totalpages: 253567 free_area_init_node: node 0, pgdat c0512c00, node_mem_map c100 DMA zone: 3963 pages, LIFO batch:0 Normal zone: 223300 pages, LIFO batch:31 HighMem zone: 24074 pages, LIFO batch:3 Using APIC driver default ACPI: PM-Timer IO Port: 0x1008 SMP: Allowing 1 CPUs, 0 hotplug CPUs Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to b000 (018bc000) PM: Registered nosave memory: 0009f000 - 000a PM: Registered nosave memory: 000a - 000ce000 PM: Registered nosave memory:
Re: More data on open-source firmware crash
Francesco Gringoli wrote: do you mind testing this firmware? It's not the solution, but can help us understanding if we should follow this way. Download at http://www.ing.unibs.it/~gringoli/fwtest.tar.gz Before using this firmware please recompile b43 changing these two definitions in b43.h #define B43_MARKER_ID_REG 52 #define B43_MARKER_LINE_REG 53 I coded the firmware so that it will raise a B43_DEBUGIRQ_MARKER with id 10, line 100 if the condition I'm thinking to is true. You will see (I hope) in dmesg. I ran the test firmware until there was a failure. The B43_DEBUGIRQ_MARKER was not present in the dmesg output. I also did as Michael suggested and preserved the depth of the tx_status queue, as well as the maximum depth observed. The latter value is 16; therefore, it is possible that the queue is being overrun. It is certainly full if the limit really is 16. I still need to look at the detailed data from the last run, but it is late here today. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
