Broadcom 4318 wireless connection drops frequently

Reported by reidi on 2010-09-26
This bug affects 7 people
Affects Status Importance Assigned to Milestone
bcmwl (Ubuntu)

Bug Description

I suspect this is a kernel regression at 2.6.35-xx. Never had a problem with Ubuntu 10.04.

Linux [myhostname] 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:34:50 UTC 2010 i686 GNU/Linux

02:00.0 Network controller [0280]: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller [14e4:4318] (rev 02)

Wireless disconnects whenever sustained data throughput is requested. So web browsing generally works, but any kind of download greater than 2-3 MB causes the connection to drop. Issuing" ifconfig wlan0 down; ifconfig wlan0 up" restores connectivity, but only for another 2-3 MB of download.

I have tried building and installing both the stable and linux-next modules at linux-wireless.org.. These modules do not solve the problem - no better, no worse.

dmesg after disconnect:

[11875.508061] No probe response from AP 00:1f:b3:68:66:a1 after 500ms, disconnecting.
[11875.509397] cfg80211: All devices are disconnected, going to restore regulatory settings

== Regression details ==
Discovered in version: maverick
Last known good version: lucid

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: bcmwl-kernel-source (not installed)
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic
Uname: Linux 2.6.35-22-generic i686
Architecture: i386
Date: Sun Sep 26 11:36:19 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta i386 (20100901.1)
SourcePackage: bcmwl

reidi (ian-reid) wrote :
reidi (ian-reid) wrote :
Download full text (3.7 KiB)

Here is dmesg wlan0 activity from boot until wireless connection failed:

[ 25.879332] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[ 25.930058] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 26.755458] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 26.812082] intel8x0_measure_ac97_clock: measured 55706 usecs (2684 samples)
[ 26.812088] intel8x0: clocking to 48000
[ 28.519904] psmouse serio2: ID: 10 00 64
[ 29.263490] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
[ 29.271976] EXT4-fs (sda7): re-mounted. Opts: commit=0
[ 31.103567] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/serio2/input/input8
[ 31.439189] EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,commit=0
[ 31.457346] EXT4-fs (sda7): re-mounted. Opts: commit=0
[ 44.025551] wlan0: authenticate with 00:1f:b3:68:66:a1 (try 1)
[ 44.027724] wlan0: authenticated
[ 44.028116] wlan0: associate with 00:1f:b3:68:66:a1 (try 1)
[ 44.029798] wlan0: RX AssocResp from 00:1f:b3:68:66:a1 (capab=0x431 status=0 aid=1)
[ 44.029803] wlan0: associated
[ 44.030841] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 44.030996] cfg80211: Calling CRDA for country: US
[ 44.084644] cfg80211: Received country IE:
[ 44.084653] cfg80211: Regulatory domain: US
[ 44.084655] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 44.084660] (2402000 KHz - 2472000 KHz @ 40000 KHz), (10000 mBi, 2700 mBm)
[ 44.084663] cfg80211: CRDA thinks this should applied:
[ 44.084665] cfg80211: Regulatory domain: US
[ 44.084668] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 44.084672] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 44.084676] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 44.084680] (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 44.084684] (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 44.084688] (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 44.084692] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[ 44.084695] cfg80211: We intersect both of these and get:
[ 44.084698] cfg80211: Regulatory domain: 98
[ 44.084700] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 44.084704] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 44.084712] cfg80211: Disabling channel 2467 MHz on phy0 due to Country IE
[ 44.084715] cfg80211: Disabling channel 2472 MHz on phy0 due to Country IE
[ 44.084718] cfg80211: Disabling channel 2484 MHz on phy0 due to Country IE
[ 44.084723] cfg80211: Current regulatory domain updated by AP to: US
[ 44.084726] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 44.084730] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 44.213399] padlock: VIA PadLock not detected.
[ 54.640033] wlan0: no IPv6 routers present
[ 795.504071] No probe response from AP 00:1f:b3:68:66:a1 after 500ms, disconnecting.
[ 795.505356] cfg80211: All devices are disconnected, going to restore regulatory settings
[ 795.505367] cfg80211: Restoring regul...


reidi (ian-reid) on 2010-10-04
tags: added: regression-potential
reidi (ian-reid) wrote :

The behavior is identical using Maverick 10.10 RC.

description: updated
Changed in bcmwl (Ubuntu Maverick):
status: New → Confirmed
tags: added: regression-release
removed: regression-potential

have experienced exactly the same problem, with the same chip and the same kubuntu version as above. Same laptop with 9.10 runs just fine. Running with almost no load runs fine too, even for a long time. As soon as for example ktorrent gets started, the issue occurs within a few seconds. So seems to be more of an throughput issue, which doesn't allow the timeout to be acknowledged within the given 500ms.

according to syslog the "No probe response from AP <mac-address> after 500ms, disconnecting." messages comes from the kernel. Could it possibly be some real time issue, some change of timeout parameters, or different scheduling / priorities due to the new kernel, and / or all this new graphics stuff?

just an idea, don't know too much about Linux interiors, but have been fighting many years with the real time OS QNX4, and came across similar situations there. Are there any timing parameters regarding this error, which can be modified, or which have been changed to this new kubuntu version?

allenc28 (allenc28) wrote :

I confirm everything reidi has reported with this bug report. The exact same hardware worked correctly with 10.04. The 10.10 upgrade broke the Broadcom 4318 device exactly as reidi described.

reidi (ian-reid) wrote :

I realize this is not a "help" forum, but I would like to let folks know that installing kernel 2.6.36-020636-generic #201010210905 resolved this problem for me. It also solved an audio glitch, https://bugs.launchpad.net/bugs/658747 .

thanks reidi, you're ahead of us, your "help desk" proposal to upgrade to kernel 2.6.36 solved all the issues I had, including the audio glitch, which came together with a video glitch when playing movies. And with the old kernel this 4318 bug clearly got worse when having increased CPU load of any kind, I ran several tests.. So all this points to some serious scheduling or priority issues, to me it is pretty obvious this really is a kernel bug..

PS: under given evidence it would be very nice if this 2.6.36 kernel could be taken as the kernel for the official 10.10 maverick distribution, especially as all the 2.6.36-rc's belong to maverick according to the mainstream kernel list..

..and I have to step back a little, the 4318 effect (purposely I don't say "bug"..) isn't fully fixed yet, although improved by an order of magnitude. Happened to me once again after some tests now, with heavy load on my system..

thanks, looks like someone had mercy with me, the latest official 10.10 kernel does the job, about the same behavior now as with the 2.6.36 kernel mentioned above, the version running now was taken from dmesg:

[ 0.000000] Linux version 2.6.35-23-generic (buildd@roseapple) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 (Ubuntu 2.6.35-23.41-generic

and same as mentioned above, the issues are not fully fixed yet, but for sure at a much better level. Since the update just 2-3 drops of the 4318 wireless connection, and only under heavy system load. Under normal conditions it runs stable for days. And if it drops, reidi's "sudo ifconfig wlan0 down/up" revives it again..

and also the latest official Maverick doesn't really solve the issue, still some dropouts when downloading torrents @~200kBytes/second, usually after 200-300 MB the dropout comes. Under all other "normal" circumstances not a single dropout for days..

[ 0.000000] Linux version 2.6.35-24-generic (buildd@vernadsky) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ) #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 (Ubuntu 2.6.35-24.42-generic

Adam Porter (alphapapa) on 2013-06-09
Changed in bcmwl (Ubuntu):
status: New → Invalid
no longer affects: bcmwl (Ubuntu Maverick)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers