Bug 42896 - Wireless with BCM4306 and b43 driver broken with kernel 3.2.9
Summary: Wireless with BCM4306 and b43 driver broken with kernel 3.2.9
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-09 17:01 UTC by Phillip Wood
Modified: 2012-03-16 13:27 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.2.9
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
portion of kernel log (5.20 KB, text/plain)
2012-03-09 17:02 UTC, Phillip Wood
Details

Description Phillip Wood 2012-03-09 17:01:55 UTC
Upon upgrading from 3.2.8 to 3.2.9 wireless networking with BCM4306 & b43 driver stops working, wlan0 never becomes available. I have attached the relevant portion of my kernel logs.
lspci -v gives (on 3.2.8)

06:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
	Subsystem: Belkin F5D7011 v1000 High-Speed Mode Wireless G Notebook Card
	Flags: bus master, fast devsel, latency 64, IRQ 11
	Memory at 38000000 (32-bit, non-prefetchable) [size=8K]
	Kernel driver in use: b43-pci-bridge

I'm using the standard kernel on Arch Linux, their kernel config is unchanged between the 3.2.8 and 3.2.9 packages.
Comment 1 Phillip Wood 2012-03-09 17:02:47 UTC
Created attachment 72561 [details]
portion of kernel log
Comment 2 John W. Linville 2012-03-09 19:57:50 UTC
I don't see any likely culprits in the log between 3.2.8 and 3.2.9.
Comment 3 Larry Finger 2012-03-09 21:46:37 UTC
Was the same firmware used with 3.2.8 as you have with 3.2.9?

The dmesg output suggests that something in user space is blocking wireless. What software was changed in addition to the kernel? Is the 3.2.8 kernel still available? If so, does b43 work when you use it without changing any other components?
Comment 4 Phillip Wood 2012-03-10 14:23:27 UTC
Reinstalling the 3.2.8 kernel fixes the problem without changing any other packages - sorry I should have made that clear yesterday. (That's what makes me think it has something to do with the kernel.) My wife's laptop has another broadcom chip and that has the same problem with the 3.2.9 kernel but is fine if I reinstall the 3.2.8 kernel without changing anything else. The Arch Linux bug report is available at 
https://bugs.archlinux.org/task/28784?string=wlan0&project=1&search_name=&type%5B0%5D=&sev%5B0%5D=&pri%5B0%5D=&due%5B0%5D=&reported%5B0%5D=&cat%5B0%5D=&status%5B0%5D=open&percent%5B0%5D=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=
someone else with the same problem has posted some logs there.

The details of my wife's wireless card from lspci -v are

03:00.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
	Subsystem: Belkin F5D7011 v2000 High-Speed Mode Wireless G Notebook Card
	Flags: bus master, fast devsel, latency 64, IRQ 11
	Memory at c8000000 (32-bit, non-prefetchable) [size=8K]
	Kernel driver in use: b43-pci-bridge

I did look at the changelog before posting the bug yesterday in the hope that there would be something obvious to try reverting but didn't find anything. (but there again I'm no kernel expert). If you want me to try something else please let me know. Is there a way to get more debugging information from the b43 driver?
Comment 5 Phillip Wood 2012-03-10 14:33:23 UTC
List of packages upgraded at the same time as the kernel, from package manager logs. As I said above the network works fine with these updates and the 3.2.8 kernel

[2012-03-09 14:23] Running '/usr/bin/pacman -Syu'
[2012-03-09 14:23] synchronizing package lists
[2012-03-09 14:23] starting full system upgrade
[2012-03-09 14:29] upgraded bluez (4.98-3 -> 4.99-1)
[2012-03-09 14:29] upgraded chromium (17.0.963.56-1 -> 17.0.963.78-1)
[2012-03-09 14:29] upgraded dialog (1.1_20111020-1 -> 1.1_20120215-1)
[2012-03-09 14:29] upgraded dnsutils (9.8.1-2 -> 9.9.0-1)
[2012-03-09 14:29] upgraded flashplugin (11.1.102.62-1 -> 11.1.102.63-1)
[2012-03-09 14:29] upgraded gcc-libs (4.6.2-7 -> 4.6.3-1)
[2012-03-09 14:29] upgraded ppl (0.11.2-2 -> 0.12-1)
[2012-03-09 14:30] upgraded gcc (4.6.2-7 -> 4.6.3-1)
[2012-03-09 14:30] upgraded gcc-objc (4.6.2-7 -> 4.6.3-1)
[2012-03-09 14:30] upgraded git (1.7.9.2-1 -> 1.7.9.3-1)
[2012-03-09 14:30] upgraded rhino (1.7R3-1 -> 1.7R3-2)
[2012-03-09 14:30] upgraded jre7-openjdk-headless (7.b147_2.1-1 -> 7.b147_2.1-3)
[2012-03-09 14:30] upgraded jre7-openjdk (7.b147_2.1-1 -> 7.b147_2.1-3)
[2012-03-09 14:30] upgraded icedtea-web-java7 (1.1.4-2 -> 1.1.5-1)
[2012-03-09 14:30] upgraded lame (3.99.4-1 -> 3.99.5-1)
[2012-03-09 14:30] upgraded libcroco (0.6.3-1 -> 0.6.4-1)
[2012-03-09 14:30] upgraded libfontenc (1.1.0-2 -> 1.1.1-1)
[2012-03-09 14:30] upgraded libice (1.0.7-2 -> 1.0.8-1)
[2012-03-09 14:31] upgraded libltdl (2.4.2-3 -> 2.4.2-4)
[2012-03-09 14:31] upgraded libsm (1.2.0-2 -> 1.2.1-1)
[2012-03-09 14:31] upgraded libtool (2.4.2-3 -> 2.4.2-4)
[2012-03-09 14:31] upgraded libxau (1.0.6-2 -> 1.0.7-1)
[2012-03-09 14:31] upgraded libxmu (1.1.0-2 -> 1.1.1-1)
[2012-03-09 14:31] >>> Updating module dependencies. Please wait ...
[2012-03-09 14:32] >>> Generating initial ramdisk, using mkinitcpio.  Please wait...
[2012-03-09 14:32] ==> Building image from preset: 'default'
[2012-03-09 14:32]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2012-03-09 14:32] ==> Starting build: 3.2.9-1-ARCH
[2012-03-09 14:32]   -> Parsing hook: [base]
[2012-03-09 14:32]   -> Parsing hook: [udev]
[2012-03-09 14:32]   -> Parsing hook: [autodetect]
[2012-03-09 14:32]   -> Parsing hook: [pata]
[2012-03-09 14:32]   -> Parsing hook: [consolefont]
[2012-03-09 14:32]   -> Parsing hook: [keymap]
[2012-03-09 14:32]   -> Parsing hook: [resume]
[2012-03-09 14:32]   -> Parsing hook: [filesystems]
[2012-03-09 14:32] ==> Generating module dependencies
[2012-03-09 14:32] ==> Creating gzip initcpio image: /boot/initramfs-linux.img
[2012-03-09 14:32] ==> Image generation successful
[2012-03-09 14:32] ==> Building image from preset: 'fallback'
[2012-03-09 14:32]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2012-03-09 14:32] ==> Starting build: 3.2.9-1-ARCH
[2012-03-09 14:32]   -> Parsing hook: [base]
[2012-03-09 14:32]   -> Parsing hook: [udev]
[2012-03-09 14:32]   -> Parsing hook: [pata]
[2012-03-09 14:32]   -> Parsing hook: [consolefont]
[2012-03-09 14:32]   -> Parsing hook: [keymap]
[2012-03-09 14:32]   -> Parsing hook: [resume]
[2012-03-09 14:32]   -> Parsing hook: [filesystems]
[2012-03-09 14:32] ==> Generating module dependencies
[2012-03-09 14:32] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
[2012-03-09 14:32] ==> Image generation successful
[2012-03-09 14:32] upgraded linux (3.2.8-1 -> 3.2.9-1)
[2012-03-09 14:34] upgraded linux-headers (3.2.8-1 -> 3.2.9-1)
[2012-03-09 14:34] upgraded lirc-utils (1:0.9.0-11 -> 1:0.9.0-12)
[2012-03-09 14:34] upgraded man-pages (3.35-1 -> 3.36-1)
[2012-03-09 14:34] upgraded mlocate (0.24-2 -> 0.25-1)
[2012-03-09 14:34] upgraded mplayer (34426-3 -> 34799-1)
[2012-03-09 14:34] upgraded networkmanager (0.9.2.0-2 -> 0.9.2.0-3)
[2012-03-09 14:34] upgraded parted (3.0-4 -> 3.1-1)
[2012-03-09 14:34] installed net-snmp (5.7.1-2)
[2012-03-09 14:35] upgraded sane (1.0.22-6 -> 1.0.22-7)
[2012-03-09 14:35] upgraded tzdata (2011n-1 -> 2012b-1)
[2012-03-09 14:35] upgraded udisks (1.0.4-1 -> 1.0.4-2)
[2012-03-09 14:35] upgraded wine (1.4rc6-1 -> 1.4-1)
[2012-03-09 14:35] upgraded xorg-fonts-encodings (1.0.4-2 -> 1.0.4-3)
Comment 6 Phillip Wood 2012-03-11 18:44:12 UTC
Some googling this afternoon revealed that the Ubuntu kernel team are currently bisecting this bug. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/947751
Comment 7 Stenten 2012-03-15 04:16:12 UTC
We bisected it over at the Ubuntu bug report [1] and found the bad commit:

aa0eb3474beae8f6d9dcc2311dc02bea50cfd7b7 is the first bad commit
commit aa0eb3474beae8f6d9dcc2311dc02bea50cfd7b7
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Feb 7 17:58:03 2012 +0100

    genirq: Unmask oneshot irqs when thread was not woken

    commit ac5637611150281f398bb7a47e3fcb69a09e7803 upstream.

    When the primary handler of an interrupt which is marked IRQ_ONESHOT
    returns IRQ_HANDLED or IRQ_NONE, then the interrupt thread is not
    woken and the unmask logic of the interrupt line is never
    invoked. This keeps the interrupt masked forever.

    This was not noticed as most IRQ_ONESHOT users wake the thread
    unconditionally (usually because they cannot access the underlying
    device from hard interrupt context). Though this behaviour was nowhere
    documented and not necessarily intentional. Some drivers can avoid the
    thread wakeup in certain cases and run into the situation where the
    interrupt line s kept masked.

    Handle it gracefully.

    Reported-and-tested-by: Lothar Wassmann <lw@karo-electronics.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 ab75402953eedef69bc60cade7653379c2f09c69 d5d5088d30573fff66356a2a87e6caafe625ae75 M kernel


[1]: launchpad.net/bugs/947751
Comment 8 John W. Linville 2012-03-15 12:11:48 UTC
Did you try adding this one?

commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Mar 6 23:18:54 2012 +0100

    genirq: Clear action->thread_mask if IRQ_ONESHOT is not set
    
    Xommit ac5637611(genirq: Unmask oneshot irqs when thread was not woken)
    fails to unmask when a !IRQ_ONESHOT threaded handler is handled by
    handle_level_irq.
    
    This happens because thread_mask is or'ed unconditionally in
    irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared.  So
    the check for !desc->thread_active fails and keeps the interrupt
    disabled.
    
    Keep the thread_mask zero for !IRQ_ONESHOT interrupts.
    
    Document the thread_mask magic while at it.
    
    Reported-and-tested-by: Sven Joachim <svenjoac@gmx.de>
    Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Comment 9 Phillip Wood 2012-03-15 16:54:58 UTC
The problem is fixed in stable kernels 3.2.10 & 3.2.11, I haven't tried the patch suggested above on it's own but looking through the changelog it is in the newer kernels.
Comment 10 Stenten 2012-03-16 03:12:39 UTC
Aye, confirmed fixed in the 3.2.11 kernel.

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