This problem did not occur in 2.6.30 through 2.6.30.6 This problem does occur in 2.6.31-rc3 through 2.6.31 When shutting down the system, a panic occurs. System: PowerMac G4 Distribution: Ubuntu Kernel is custom built / mainline. backtrace is: ssb_device_enable [ssb] (unreliable) b43_is_hw_radio_enabled [b43] b43_rfkill_poll [b43] ieee80211_rfkill_poll [mac80211] cfg80211_rfkill_poll [cfg80211] rfkill_poll [rfkill]
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 .