Bug 983318 - degraded Broadcom BCM4313 performance after upgrade to Fedora 18 and 19 [NEEDINFO]
degraded Broadcom BCM4313 performance after upgrade to Fedora 18 and 19
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: John Greene
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-10 20:25 EDT by cp_n18
Modified: 2014-06-23 10:40 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-23 10:40:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jforbes: needinfo?


Attachments (Terms of Use)
dmesg from Fedora 19 (71.18 KB, text/plain)
2013-08-05 20:07 EDT, cp_n18
no flags Details
lspci output from Fedora 19 (15.81 KB, text/plain)
2013-08-05 20:07 EDT, cp_n18
no flags Details
dmesg from Fedora 17 (65.87 KB, text/plain)
2013-08-05 20:17 EDT, cp_n18
no flags Details
lspci output from Fedora 17 (15.53 KB, text/plain)
2013-08-05 20:18 EDT, cp_n18
no flags Details
lspci -nnvv (28.86 KB, text/plain)
2013-11-01 14:26 EDT, Marcos Mello
no flags Details
output of lspci -nnvv (34.96 KB, text/plain)
2014-03-14 11:10 EDT, Joshua
no flags Details
contents of '/sys/kernel/debug/brcmsmac/bcma0:0/hardware' (121 bytes, text/plain)
2014-03-14 12:00 EDT, Joshua
no flags Details

  None (edit)
Description cp_n18 2013-07-10 20:25:43 EDT
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:
Comment 1 cp_n18 2013-07-10 20:27:36 EDT
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.
Comment 2 John Greene 2013-08-05 09:29:02 EDT
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.
Comment 3 cp_n18 2013-08-05 20:07:15 EDT
Created attachment 783076 [details]
dmesg from Fedora 19
Comment 4 cp_n18 2013-08-05 20:07:59 EDT
Created attachment 783077 [details]
lspci output from Fedora 19
Comment 5 cp_n18 2013-08-05 20:17:25 EDT
Created attachment 783078 [details]
dmesg from Fedora 17
Comment 6 cp_n18 2013-08-05 20:18:13 EDT
Created attachment 783079 [details]
lspci output from Fedora 17
Comment 7 cp_n18 2013-08-05 20:20:25 EDT
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.
Comment 8 John Greene 2013-08-06 15:11:55 EDT
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?
Comment 9 cp_n18 2013-08-07 21:05:18 EDT
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
Comment 10 Savinov Artem 2013-08-31 13:52:58 EDT
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.
Comment 11 soumen 2013-09-07 07:06:59 EDT
Any move on this bug?
Comment 12 John Greene 2013-09-18 10:16:27 EDT
 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?
Comment 13 Josh Boyer 2013-09-18 16:26:28 EDT
*********** 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.
Comment 14 cp_n18 2013-09-19 06:16:12 EDT
> *********** 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)
Comment 15 cp_n18 2013-09-19 06:18:51 EDT
(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!
Comment 16 John Greene 2013-09-20 09:48:38 EDT
(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@tuxdriver.com>
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.
Comment 17 Marcos Mello 2013-11-01 14:21:05 EDT
(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
Comment 18 Marcos Mello 2013-11-01 14:26:43 EDT
Created attachment 818401 [details]
lspci -nnvv

From a Lenovo ThinkPad Edge E430
Comment 19 Arend van Spriel 2013-11-01 16:45:19 EDT
(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?
Comment 20 Marcos Mello 2013-11-01 17:25:08 EDT
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)
Comment 21 John Greene 2013-12-06 11:28:11 EST
(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?
Comment 22 cp_n18 2013-12-06 13:19:03 EST
I always "cold boot", problem is still persisting...
Comment 23 Marcos Mello 2013-12-06 18:54:20 EST
(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
Comment 24 Savinov Artem 2013-12-21 11:35:35 EST
after  update to fedora 20 everything works well.
kernel 3.12.5-302.fc20.x86_64
Comment 25 cp_n18 2013-12-26 20:00:45 EST
I've updated my laptop to F20... same degraded performance.
Comment 26 Savinov Artem 2013-12-27 09:12:16 EST
(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.
Comment 27 Michele Baldessari 2013-12-27 12:29:32 EST
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
Comment 28 cp_n18 2013-12-27 18:35:15 EST
(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.
Comment 29 Justin M. Forbes 2014-03-10 10:49:42 EDT
*********** 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.
Comment 30 Joshua 2014-03-12 21:47:06 EDT
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
Comment 31 John Greene 2014-03-14 09:28:14 EDT
(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..
Comment 32 Joshua 2014-03-14 11:10:12 EDT
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.
Comment 33 Arend van Spriel 2014-03-14 11:45:38 EDT
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
Comment 34 Arend van Spriel 2014-03-14 11:50:01 EDT
(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
Comment 35 Joshua 2014-03-14 12:00:58 EDT
Created attachment 874504 [details]
contents of '/sys/kernel/debug/brcmsmac/bcma0:0/hardware'
Comment 36 Justin M. Forbes 2014-05-21 15:30:00 EDT
*********** 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.
Comment 37 Justin M. Forbes 2014-06-23 10:40:34 EDT
*********** 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.

Note You need to log in before you can comment on or make changes to this bug.