Description of problem: Using the b43 driver, I receive a top download speed of 40 kB/s. I downloaded kernel 2.6.24-rc3 from git and tested it with both the b43 and bcm43xx drivers. I downloaded the same file from the same server with each driver. b43 once again could only reach 40 KB/s, but bcm43xx managed 450 kB/s. The kmod-ndiswrapper from livna also was capable of +400 kB/s. Version-Release number of selected component (if applicable): kernel-2.6.23.8-63.fc8 2.6.24-rc3 kernel-2.6.23.1-49.fc8 as well as others firmware is from: broadcom-wl-4.80.53.0.tar.bz2 Additional info: Full dmesg output is attached. [rob@roblaptop ~]$ dmesg | grep b43 b43-phy0: Broadcom 4311 WLAN found b43-phy0 debug: Found PHY: Analog 4, Type 2, Revision 8 b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy0:tx Registered led device: b43-phy0:rx b43-phy0 debug: Chip initialized b43-phy0 debug: 32-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 b43-phy0 debug: Removing Interface type 2 b43-phy0 debug: Wireless interface stopped b43-phy0 debug: DMA-32 0x0200 (RX) max used slots: 1/64 b43-phy0 debug: DMA-32 0x0220 (TX) max used slots: 20/128 b43-phy0 debug: Loading firmware version 351.126 (2006-07-29 05:54:02) Registered led device: b43-phy0:tx Registered led device: b43-phy0:rx b43-phy0 debug: Chip initialized b43-phy0 debug: 32-bit DMA initialized b43-phy0 debug: Wireless interface started b43-phy0 debug: Adding Interface type 2 [rob@roblaptop ~]$ dmesg | grep wlan0 ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:09:5b:70:2d:68 wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:09:5b:70:2d:68 wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=5) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:09:5b:70:2d:68 wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:09:5b:70:2d:68 wlan0: RX AssocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=5) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:09:5b:70:2d:68 wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:09:5b:70:2d:68 wlan0: RX ReassocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=6) wlan0: associated wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:09:5b:70:2d:68 wlan0: RX authentication from 00:09:5b:70:2d:68 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:09:5b:70:2d:68 wlan0: RX ReassocResp from 00:09:5b:70:2d:68 (capab=0x5 status=0 aid=7) wlan0: associated wlan0: no IPv6 routers present [rob@roblaptop ~]$ /sbin/lspci 00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 10) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:05.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:06.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 14) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] 05:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) 08:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 08:01.0 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 08:01.1 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) ping my router: [rob@roblaptop ~]$ ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=2.40 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=2.47 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=2.44 ms ping fedoraproject: [rob@roblaptop ~]$ ping www.fedoraproject.org PING fedoraproject.org (209.132.176.122) 56(84) bytes of data. 64 bytes from wiki.fedoraproject.org (209.132.176.122): icmp_seq=1 ttl=111 time=116 ms 64 bytes from wiki.fedoraproject.org (209.132.176.122): icmp_seq=2 ttl=111 time=116 ms 64 bytes from wiki.fedoraproject.org (209.132.176.122): icmp_seq=5 ttl=111 time=125 ms Not sure if it's relevant, but I was receiving APIC errors, so I am now booting with noapic. This issue with b43 was seen both with and without noapic though. This is a Dell Inspiron 1501.
Created attachment 278981 [details] Full dmesg output
Related to bug 412861? Only there they say that -49.fc8 works OK...? mvtodevnull, can you do a git-bisect? Perhaps we can isolate this upstream?
That bug might be related, but my connection doesn't drop, it's just a steady slow connection. And -49.fc8 isn't any better. I forgot to mention that this is an 802.11g card connecting to an 802.11b router (Netgear MR814v2). Also, the bit rate starts at 1 Mb/s but quickly changes to and stays at 11 Mb/s. I'm currently working on finding a good starting point for a git-bisect. I tried the original b43 commit ([B43]: add mac80211-based driver for modern BCM43xx devices), but it showed the same behavior. Certain points inbetween that commit and current were a bit faster (I got up to 60 kB/s at one point!), but still very slow. I'm now going to try the wireless-dev git and see if I have any better luck with that.
In case it's helpful, some more information about the hardware: 05:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01) Subsystem: Dell Unknown device 0007 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at b0200000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=2 PME- Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: 00000000 Data: 0000 Capabilities: [d0] Express Legacy Endpoint IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+ Device: Latency L0s <4us, L1 unlimited Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0 Link: Latency L0s <4us, L1 <64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 I'll attach the full output of lspci -vv.
Created attachment 280501 [details] Output of lspci -vv
No luck with wireless-dev git either. I tried to load the driver with pio=1 just to see what would happen, and I got: This card does not support PIO operation mode. Please use DMA mode (module parameter pio=0). So it's definitely using dma mode. How should I proceed? I understand the developers can't have every piece of hardware, so I don't mind trying to improve the performance myself, but some help would be appreciated. Is there any information I can provide that might help? Are there any parts of the driver code that I can try to tweak? Anything?
read the code. I mean, If there was a way I could say "You must look at this and that part of the code" I would do it myself and fix the stuff. We don't know what most of the PHY code does. So if you want to do something you'll have to look into the code yourself and find a place which might be broken. Doing this probably means comparing thousands of lines of code to the specifications; changing something; testing; starting over... Good luck.
Hi Michael, thanks for the reply. This might be like David fighting Goliath, but I'll give it a try.
Duplicate of bug 412861?
Alexei, please see comment 2 and comment 3...
I suspect that this was caused by a regression in A PHY init. Could you try an updated wireless-2.6 tree now?
http://koji.fedoraproject.org/koji/buildinfo?buildID=30116 The kernels at the link above should have all the wireless bits from the current wireless-2.6 tree. Give that a try?
I've tried the latest wireless-2.6 and unfortunately, no change.
*** Bug 430210 has been marked as a duplicate of this bug. ***
Re: bug 430210; 2.6.23.14-107.fc8 gives me 1.6MB/s throughput which is very good relative to the other ~90KB/s throughputs. Please make sure to check my bug report as I will continue to add performance benchmarks to help isolate this issue when any new kernels are released (or put in updates-testing). Thanks for the hard work being put into this. I'm glad my hardware works at all without ndiswrapper.
2.6.23.15-137.fc8 gives me ~1.3MB/s and I will test if it works on 802.11b sometime soonish.
2.6.23.15-137.fc8 does not work on 802.11b for me.
Could you define "does not work on 802.11b"? You mean it performs poorly? Or it does not associate at all? While you are poking around, would you mind trying a recent rawhide kernel? http://koji.fedoraproject.org/koji/buildinfo?buildID=35801 The wireless bits in the F8 kernels are a bit behind, fwiw...
The card associates correctly, and is even able to get a valid lease. However, no packets make it out of the interface after the lease is obtained. ping only works to the lease IP (and localhost), no other IP traffic can get out of the card. Anything more I can test with regards to 802.11b not working? With regards to trying rawhide, I'd be willing to try a live image of rawhide... maybe I'll spin one up tonight and test it. I need my laptop working and don't want to deal with enabling development.
Re: rawhide -- you can run a rawhide kernel (as in comment 18) w/o updating everything form the development tree If you have another box available that can run wireshark (even windows), it might be helpful to have a capture of that traffic. If you are getting a lease then it would seem like the card is at least basically working.
for me the kernel-2.6.23.15-137.fc8 still has problem. the strange thing it's working eg. i can browse the web, but when i do some long network talk eg: rsync through the net it's hang after the same time (ie: rsync start to count the filelist and hang at 6600, but if i plug it to the wirelass router by cable then everything works correctly). i've hp 6125 with: 02:02.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02) and it was worked a few mounts ago correctly.
i try the #118 kernel but it's not boot for me on my hp 6125 (can't find root) so i can't try whether it's better or not:-(
Comment 21 sounds like the TCP window scaling issue: http://lwn.net/Articles/92727/ You might try this: echo 0 > /proc/sys/net/ipv4/tcp_default_win_scale Does that help with the "long network talk"?
unfortunately th problem disappear in the last week?:-) but if it's happend again i'll try this. thanks.
OK...this bug has gotten pretty scrambled. I'm going to close this as CURRENTRELEASE. Please open a new bug for the 802.11b issue and for any other specific performance problems observed...thanks!