Description of problem: Network performance has degraded after upgrade from Fedora 17 to 18, problem continues to exist in Fedora 19. Fedora 18 & 19 suffers from slow performance and WiFi timeouts. Output from iwconfig confirms that Link Quality and Signal levels are different between the two releases. Version-Release number of selected component (if applicable): 02:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) How reproducible: Always. Steps to Reproduce: 1. Boot laptop with Fedora 17, record iwconfig output 2. Boot laptop with Fedora 19, record iwconfig output 3. Notice difference in Link Quality and Signal Level. 4. Performance is restored when you reboot back to Fedora 17. Actual results: iwconfig output from Fedora 19: (3.9.9-301.fc19.x86_64) wlp2s0 IEEE 802.11bgn ESSID:"603PENGWIN" Mode:Managed Frequency:2.412 GHz Access Point: 00:1C:10:66:BB:F6 Bit Rate=5.5 Mb/s Tx-Power=19 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=20/70 Signal level=-90 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:20 Missed beacon:0 Expected results: iwconfig output from Fedora 17: eth3 IEEE 802.11abg ESSID:"603PENGWIN" Mode:Managed Frequency:2.412 GHz Access Point: 00:1C:10:66:BB:F6 Bit Rate=54 Mb/s Tx-Power=200 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=56/70 Signal level=-54 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Additional info:
Laptop is about 12feet away from LinkSys WAP54G access point. At twice that distance, Fedora 18 and 19 no longer connect to the access point.
Hmm..Curious. Can upload the output of this: lspci -nnvv and the output of: dmesg > dmesg.txt Will take a look for you. At 12 feet that is certainly a problem. What range can you get with F17 usually? If you can boot one then the other and repeat the situation that validates the hardware setup is ok. Is it possible the antenna connections/antenna is ok? After having the problem on f19, you can boot f17 and get back to good signal? Need to eliminate a easy hardware issue.
Created attachment 783076 [details] dmesg from Fedora 19
Created attachment 783077 [details] lspci output from Fedora 19
Created attachment 783078 [details] dmesg from Fedora 17
Created attachment 783079 [details] lspci output from Fedora 17
Same hardware, if I boot with 17 it's good... boot with 19, it's poor... and then back to 17 and it's good. I think this rules out the hardware as the problem. I'll check the range when I get a chance.
Thanks for the files. Yup, likely does rule out hardware..which is. 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01 Are you using bluetooth? Might try to disable and see it that helps as a test. rfkill list shows something like: 0: tpacpi_bluetooth_sw: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 2: hci0: Bluetooth Soft blocked: no Hard blocked: no then: rfkill block 2 Then check your signal for any change. Not sure it's an issue but easy to eliminate it. They share same radio spectrum. Perhaps some change in driver since f17. there are a ton. Have you tried 3.10.x?
Kernel: 3.10.4-300.fc19.x86_64 using rfkill to shutoff Bluetooth had no effect.. 0: hci0: Bluetooth Soft blocked: yes Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 2: hp-wifi: Wireless LAN Soft blocked: no Hard blocked: no 3: hp-bluetooth: Bluetooth Soft blocked: no Hard blocked: no
I have the same problem. 3.10.9-200.fc19.x86_64 03:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01) Subsystem: Broadcom Corporation Device 0608 Kernel driver in use: bcma-pci-bridge Turn off bluetooth also does not give effect.
Any move on this bug?
Took a deeper look at your logs: your system is using 2 different drivers here depending on the version you boot. Going forward the smac driver would be a better idea if you can work through the issue with signal strength..Frustrating answer I know, but we need to get apples to apples issues. For F17, it's using the older b43/wl driver: 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01) ... Kernel driver in use: wl On f19, it's using the newer brcmsmac driver: 02:00.0 Network controller [0280]: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller [14e4:4727] (rev 01) ... Kernel driver in use: bcma-pci-bridge You can use whatever you like, but please know that b43 driver is not supported by Broadcom: it's reverse engineered. They DO support the brcmsmac driver for your device. To enable the smac driver in your kernel, you Please disable it in your .config. Turning-off CONFIG_B43_BCMA_EXTRA should be sufficient. You should be able to blacklist the driver(s) you don't want if you want to stay with b43 also. Which path do you think you'll take?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
> *********** MASS BUG UPDATE ************** > > Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel > update and let us know if you issue has been resolved or if it is still > present with the newer kernel. Just updated to the 3.11.1-200 kernel, no change.(In reply to Josh Boyer from comment #13)
(In reply to John Greene from comment #12) > Took a deeper look at your logs: your system is using 2 different drivers > here depending on the version you boot. Going forward the smac driver would > be a better idea if you can work through the issue with signal > strength..Frustrating answer I know, but we need to get apples to apples > issues. > > Which path do you think you'll take? I was unaware that two different drivers were involved. As far as I know, I've only been using the drivers that were provided by the Fedora distribution. I agree that going forward with the smac driver would the better idea. Thanks!
(In reply to cp_n18 from comment #15) > I agree that going forward with the smac driver would the better idea. > Thanks! So, the next issue is figuring why signal strength is so low, on apparently good hardware.. On this part I see a couple patches that came and were reverted for 4313iPA: commit 54683441a92ebe20c5282465ea6f21e5e74d2974 Author: John W. Linville <linville> Date: Wed Mar 27 10:52:11 2013 -0400 Revert "brcmsmac: support 4313iPA" This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. This commit is reported to cause a regression in the support for some revisions of 4313 ePA devices. The original patch (b6fc28a158076ca2764edc9a6d1e1402f56e1c0c) was in 3.7 and the revert was done in 3.9, which will be close to the 3.11 you just tested. Would you be able to try the smac driver in these 2 kernels and see if they might fix the signal strength issues any? From your original post: check these numbers and post for me, with 3.7 kernel and the #'s on 3.11. These look BAD: wlp2s0 IEEE 802.11bgn ESSID:"603PENGWIN" Mode:Managed Frequency:2.412 GHz Access Point: 00:1C:10:66:BB:F6 Bit Rate=5.5 Mb/s Tx-Power=19 dBm ^^^^^^^^ Transmit side^^^^^^^^^^^^^ Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=20/70 Signal level=-90 dBm ^^^^^^^^^^^ Rx side ^^^^^^^^^^^^^^^^^^^^ Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:20 Missed beacon:0 Expected results: These look GOOD: eth3 IEEE 802.11abg ESSID:"603PENGWIN" Mode:Managed Frequency:2.412 GHz Access Point: 00:1C:10:66:BB:F6 Bit Rate=54 Mb/s Tx-Power=200 dBm ^^^^^^^^ Transmit side^^^^^^^^^^^^^ Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=56/70 Signal level=-54 dBm ^^^^^^^^^^^ Rx side ^^^^^^^^^^^^^^^^^^^^ Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Relizes these number are dynamic and you can get a few snapshots and see if they are changing.
(In reply to John Greene from comment #16) > So, the next issue is figuring why signal strength is so low, on apparently > good hardware.. > I'm experiencing *very* poor signal strength here too. Wlan only connects when very close to the AP. Two meters from the AP, one wall between: wlp3s0 IEEE 802.11bgn ESSID:"Darkstar" Mode:Managed Frequency:2.447 GHz Access Point: F8:1A:67:CB:97:DC Bit Rate=21.7 Mb/s Tx-Power=19 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=36/70 Signal level=-74 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:157 Invalid misc:1329 Missed beacon:0 Most of the time bitrate is at ~21 Mb/s. My old laptop (*cough* Atheros Wlan *cough*) had a much much better signal strength in the same place. Basically BCM4313 is unusable with brcmsmac. kernel-3.11.6-200.fc19.x86_64
Created attachment 818401 [details] lspci -nnvv From a Lenovo ThinkPad Edge E430
(In reply to Marcos Mello from comment #17) > (In reply to John Greene from comment #16) > > So, the next issue is figuring why signal strength is so low, on apparently > > good hardware.. > > > > I'm experiencing *very* poor signal strength here too. Wlan only connects > when very close to the AP. Do you mean this is a regression, ie. it was fine with older kernels?
I do not think so. I run openSUSE 12.3 (3.7 kernel) for some days before Fedora 19. It was pretty bad too, but I did not do further tests. In the kernel log, relevant messages are PM: resume of devices complete after 3093.429 msecs PM: Finishing wakeup. Restarting tasks ... done. video LNXVIDEO:00: Restoring backlight state brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: false (implement) brcmsmac bcma0:0: brcms_ops_config: change power-save mode: false (implement) IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready r8169 0000:0c:00.0 p3p1: link down IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready wlp3s0: authenticate with f8:1a:67:cb:97:dc wlp3s0: send auth to f8:1a:67:cb:97:dc (try 1/3) wlp3s0: authenticated wlp3s0: associate with f8:1a:67:cb:97:dc (try 1/3) wlp3s0: RX AssocResp from f8:1a:67:cb:97:dc (capab=0x431 status=0 aid=2) brcmsmac bcma0:0: brcmsmac: brcms_ops_bss_info_changed: associated brcmsmac bcma0:0: brcms_ops_bss_info_changed: qos enabled: true (implement) wlp3s0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlp3s0: link becomes ready brcmsmac bcma0:0: brcms_ops_bss_info_changed: arp filtering: 1 addresses (implement)
(In reply to Marcos Mello from comment #20) > PM: resume of devices complete after 3093.429 msecs > PM: Finishing wakeup. > Restarting tasks ... done. Just noticed the resume. Hmmm. Does this occur from cold boot as well as from resume? Is signal strength good before resume and bad after? Or same both times?
I always "cold boot", problem is still persisting...
(In reply to John Greene from comment #21) > (In reply to Marcos Mello from comment #20) > > > PM: resume of devices complete after 3093.429 msecs > > PM: Finishing wakeup. > > Restarting tasks ... done. > > Just noticed the resume. Hmmm. Does this occur from cold boot as well as > from resume? Is signal strength good before resume and bad after? Or same > both times? It does not matter. Poor signal with cold boot too. Now, I am a bit farther from the AP and the connection hangs constantly. This laptop still has Windows 7 in dual boot. There, it shows 4 of 5 bars (sometimes full 5) of signal strength. Same place. :( wlp3s0 IEEE 802.11bgn ESSID:"Darkstar" Mode:Managed Frequency:2.447 GHz Access Point: F8:1A:67:CB:97:DC Bit Rate=65 Mb/s Tx-Power=19 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=23/70 Signal level=-87 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:2069 Invalid misc:719 Missed beacon:0 kernel-3.11.9-200.fc19.x86_64
after update to fedora 20 everything works well. kernel 3.12.5-302.fc20.x86_64
I've updated my laptop to F20... same degraded performance.
(In reply to cp_n18 from comment #25) > I've updated my laptop to F20... same degraded performance. you have installed the package b43-firmware(b43-firmware-5.100.138-1.fc17.noarch)? if yes, then try to remove it.
For those experiencing poor tcp performance over wireless in general, kernels >= 3.12.4 have the "tcp: tsq: restore minimal amount of queueing" patch which helps for tcp case only. It is strictly a tcp layer patch and has nothing to do with NIC drivers. I think it is worth mentioning as the regression was introduced in 3.12 and hit wireless nics in general
(In reply to Savinov Artem from comment #26) > (In reply to cp_n18 from comment #25) > > I've updated my laptop to F20... same degraded performance. > > you have installed the package > b43-firmware(b43-firmware-5.100.138-1.fc17.noarch)? > if yes, then try to remove it. Nope... no b43-firmware packages installed.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I am running fc19 3.13.5-103.fc19.x86_64 and the kernel brcmsmac driver fails. I can connect to my router but the connection get slower and slower and then stops receiving or sending data. 12:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless Network Adapter (rev 01) Subsystem: Dell Inspiron M5010 / XPS 8300 Flags: bus master, fast devsel, latency 0, IRQ 17 Memory at fbd00000 (64-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [58] Vendor Specific Information: Len=78 <?> Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [d0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [13c] Virtual Channel Capabilities: [160] Device Serial Number 00-00-9d-ff-ff-71-1c-65 Capabilities: [16c] Power Budgeting <?> Kernel driver in use: bcma-pci-bridge
(In reply to Joshua from comment #30) > I am running fc19 3.13.5-103.fc19.x86_64 and the kernel brcmsmac driver > fails. > I can connect to my router but the connection get slower and slower and then > stops receiving or sending data. > > 12:00.0 Network controller: Broadcom Corporation BCM4313 802.11bgn Wireless > Network Adapter (rev 01) > Subsystem: Dell Inspiron M5010 / XPS 8300 > Flags: bus master, fast devsel, latency 0, IRQ 17 > Memory at fbd00000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [40] Power Management version 3 > Capabilities: [58] Vendor Specific Information: Len=78 <?> > Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ > Capabilities: [d0] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [13c] Virtual Channel > Capabilities: [160] Device Serial Number 00-00-9d-ff-ff-71-1c-65 > Capabilities: [16c] Power Budgeting <?> > Kernel driver in use: bcma-pci-bridge Well Joshua, this device isn't claimed by brcmsmac driver, no joy there. Can you add output of lspci -nnvv for this guy? Need the device ID..
Created attachment 874489 [details] output of lspci -nnvv I'm using a usb wireless adapter since the internal broadcom only works with windows these days.
The device probably is claimed by brcmsmac. The bcma-pci-bridge is a bus driver providing brcmsmac host-interface agnostic access to the device. So you really need to check sysfs, ie. under /sys/bus/bcma/devices/... Please provide content of /sys/kernel/debug/brcmsmac/bcma*/hardware
(In reply to Arend van Spriel from comment #33) > The device probably is claimed by brcmsmac. The bcma-pci-bridge is a bus > driver providing brcmsmac host-interface agnostic access to the device. So > you really need to check sysfs, ie. under /sys/bus/bcma/devices/... > > Please provide content of /sys/kernel/debug/brcmsmac/bcma*/hardware
Created attachment 874504 [details] contents of '/sys/kernel/debug/brcmsmac/bcma0:0/hardware'
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.14.4-100.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.