Bug 14181

ProblemType: KernelOops
Annotation: Your system might become unstable now and might need to be restarted.
Date: Thu Sep 24 12:51:06 2009
Failure: oops
OopsText:
 ADDRCONF(NETDEV_UP): wlan0: link is not ready
 Machine check in kernel mode.
 Caused by (from SRR1=149030): Transfer error ack signal
 Oops: Machine check, sig: 7 [#1]
 PowerMac
 Modules linked in: b43 binfmt_misc ppdev lp parport rfcomm sco bridge stp bnep l2cap radeon drm ipv6 cpufreq_stats therm_adt746x sbp2 arc4 apm_emu apm_emulation snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa snd_seq_dummy snd_seq_oss snd_seq_midi ecb snd_aoa_i2sbus snd_rawmidi snd_seq_midi_event snd_pcm_oss pcmcia snd_mixer_oss snd_seq snd_pcm mac80211 yenta_socket cfg80211 snd_seq_device rsrc_nonstatic snd_timer btusb uninorth_agp snd_page_alloc bluetooth pcmcia_core rfkill joydev snd_aoa_soundbus ams appletouch pmac_zilog input_polldev agpgart serial_core rtc_generic evdev iptable_filter ip_tables x_tables snd soundcore hid_apple ohci1394 sungem sungem_phy usbhid hid windfarm_core ieee1394 ssb [last unloaded: b43]
 NIP: c001bb6c LR: f1078610 CTR: c001bb64
 REGS: ef87fe10 TRAP: 0200   Not tainted  (2.6.31-10-powerpc)
 MSR: 00149030 <EE,ME,IR,DR>  CR: 44000082  XER: 00000000
 TASK = ef84bd40[5] 'events/0' THREAD: ef87e000
 GPR00: c1c7b050 ef87fec0 ef84bd40 000039c0 0000049a 00010000 00000002 00000010 
 GPR08: 00000000 f107aff4 00000000 c001bb64 24000082 00000000 0021b960 0021b9e4 
 GPR16: 0021b93c 0021bb28 002413b0 0021b860 ef84bd40 eb80f300 c0505984 c05059bc 
 GPR24: c0553564 ec7e29c0 c1c7b000 00000001 ec7e21a0 f27145f4 0000049a c1c7b000 
 NIP [c001bb6c] ioread16+0x8/0x18
 LR [f1078610] ssb_pci_read16+0x30/0x68 [ssb]
 Call Trace:
 [ef87fec0] [f1076b58] ssb_device_enable+0xe0/0x118 [ssb] (unreliable)
 [ef87fed0] [f34c68e0] b43_is_hw_radio_enabled+0x60/0x74 [b43]
 [ef87fee0] [f34c693c] b43_rfkill_poll+0x48/0x134 [b43]
 [ef87ff10] [f28daa60] ieee80211_rfkill_poll+0x34/0x44 [mac80211]
 [ef87ff20] [f2854020] cfg80211_rfkill_poll+0x20/0x30 [cfg80211]
 [ef87ff30] [f2714620] rfkill_poll+0x2c/0x54 [rfkill]
 [ef87ff40] [c0057704] run_workqueue+0xd0/0x178
 [ef87ff80] [c005784c] worker_thread+0xa0/0x124
 [ef87ffc0] [c005c384] kthread+0x78/0x7c
 [ef87fff0] [c001646c] kernel_thread+0x4c/0x68
 Instruction dump:
 bbc10008 38210010 7c0803a6 4e800020 7c0004ac 88630000 0c030000 4c00012c 
 5463063e 4e800020 7c0004ac 7c601e2c <0c030000> 4c00012c 5463043e 4e800020 
 ---[ end trace 6d7b59613f187151 ]---
 
Package: linux-image-2.6.31-10-powerpc
SourcePackage: linux
Tags: kernel-oops

Created attachment 23233 [details]
Proposed Patch

Does this patch fix the problem?

Created attachment 23234 [details]
Revised patch

The previous patch was wrong. Does this one fix the problem?

I will give it a try on Wednesday and let you know.

That patch doesn't apply against 2.6.31 git.  I'm guessing it's master.
2.6.31 has this version:

static void b43_op_stop(struct ieee80211_hw *hw)
{
        struct b43_wl *wl = hw_to_b43_wl(hw);
        struct b43_wldev *dev = wl->current_dev;

        cancel_work_sync(&(wl->beacon_update_trigger));
 
        mutex_lock(&wl->mutex);
        if (b43_status(dev) >= B43_STAT_STARTED)
                b43_wireless_core_stop(dev);
        b43_wireless_core_exit(dev);
        wl->radio_enabled = 0;
        mutex_unlock(&wl->mutex); 
                        
        cancel_work_sync(&(wl->txpower_adjust_work));
}

I'm adding wiphy_rfkill_stop_polling(hw->wiphy); after the mutex_lock and am rebuilding now.

That should fix your panic, but it may introduce a locking problem. I found late yesterday that the new statement should be before the mutex_lock.

I moved it before the lock.  I'm no longer panicing when taking down the b43 interface.

Thanks for the bug report and the testing.

I just learned that my fix for your problem caused problems for others because once the rfkill switch is activated, it will no longer be honored.

Does your interface have a switch to kill the RF?

If you apply both hunks of the following patch, does your interface work? Note: The first hunk just removes the previous patch.

Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4501,7 +4501,6 @@ static void b43_op_stop(struct ieee80211

        cancel_work_sync(&(wl->beacon_update_trigger));

-       wiphy_rfkill_stop_polling(hw->wiphy);
        mutex_lock(&wl->mutex);
        if (b43_status(dev) >= B43_STAT_STARTED) {
                dev = b43_wireless_core_stop(dev);
Index: wireless-testing/drivers/net/wireless/b43/rfkill.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/rfkill.c
+++ wireless-testing/drivers/net/wireless/b43/rfkill.c
@@ -33,7 +33,8 @@ bool b43_is_hw_radio_enabled(struct b43_
                      & B43_MMIO_RADIO_HWENABLED_HI_MASK))
                        return 1;
        } else {
-               if (b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
+               if (b43_status(dev) >= B43_STAT_STARTED &&
+                   b43_read16(dev, B43_MMIO_RADIO_HWENABLED_LO)
                    & B43_MMIO_RADIO_HWENABLED_LO_MASK)
                        return 1;
        }

One additional request: Please post the output of

dmesg | egrep "ssb|b43"

Thanks.

I am remote from the machine until Monday, so I'll give it a try next week...  In the mean time, here's the dmesg output;

Here is the dmesg output:

[   12.610984] b43-pci-bridge 0001:10:12.0: enabling device (0004 -> 0006)
[   12.614876] ssb: Sonics Silicon Backplane found on PCI device 0001:10:12.0
[   14.082002] b43-phy0: Broadcom 4306 WLAN found (core revision 5)
[   21.367392] b43 ssb0:0: firmware: requesting b43/ucode5.fw
[   21.779791] b43 ssb0:0: firmware: requesting b43/pcm5.fw
[   21.828872] b43 ssb0:0: firmware: requesting b43/b0g0initvals5.fw
[   21.995709] b43 ssb0:0: firmware: requesting b43/b0g0bsinitvals5.fw
[   22.229408] b43-phy0: Loading firmware version 410.2160 (2007-05-26 15:32:10)
[   22.281519] Registered led device: b43-phy0::tx
[   22.281558] Registered led device: b43-phy0::rx
[   22.281581] Registered led device: b43-phy0::radio

This is with 2.6.31.2 with your original patch applied.

How can I check if it has a switch to kill the RF?

It will be on the computer. If this is a PCMCIA card, then no switch.

Oh, yeah... there is definitely no physical switch.  This is a PowerBook G4.

The second patch that you provided (adding the check for b43_status(dev) >= B43_STAT_STARTED) avoids the panic.

On Monday 12 October 2009, Jeremy Huddleston wrote:
> Yes, it should still be listed.
> 
> On Oct 11, 2009, at 16:01, Rafael J. Wysocki wrote:
> 
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.30 and 2.6.31.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.30 and 2.6.31.  Please verify if it still  
> > should
> > be listed and let me know (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=14181
> > Subject             : b43 causes panic at ifconfig down / shutdown
> > Submitter   : Jeremy Huddleston <jeremyhu@freedesktop.org>
> > Date                : 2009-09-15 18:34 (27 days old)

Fixed by commit d50bae33d1358b909ade05ae121d83d3a60ab63f .