Bug 413291
| Summary: | very low performace with b43 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mvtodevnull | ||||||
| Component: | kernel | Assignee: | John W. Linville <linville> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 8 | CC: | cebbert, davej, jonathansteffan, mb, stefano.brivio | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 2.6.23.15-137.fc8 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-02-20 14:27:16 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
mvtodevnull
2007-12-06 01:34:18 UTC
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? 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! |