Michael Buesch wrote: > On Sunday 16 December 2007 17:20:19 Johannes Berg wrote: >> Hi, >> >> Just booted into my shiny new #everything and got: >> >> [ 40.209739] BUG: sleeping function called from invalid context at kernel/rwsem.c:47 >> [ 40.220119] in_atomic():1, irqs_disabled():0 >> [ 40.230514] Call Trace: >> [ 40.240799] [eec2fc90] [c0009198] show_stack+0x4c/0x1ac (unreliable) >> [ 40.251247] [eec2fcd0] [c0027a3c] __might_sleep+0xd0/0xf0 >> [ 40.261620] [eec2fce0] [c004c1d0] down_write+0x24/0x64 >> [ 40.271974] [eec2fcf0] [c026347c] led_trigger_register+0xbc/0x118 >> [ 40.282273] [eec2fd10] [f250246c] ieee80211_led_init+0x68/0x160 [mac80211] >> [ 40.292837] [eec2fd30] [f24eceb0] ieee80211_register_hw+0x200/0x324 [mac80211] >> [ 40.303295] [eec2fd40] [f2523234] b43_probe+0x9a8/0xa04 [b43] >> [ 40.313766] [eec2fda0] [f20b06e8] ssb_device_probe+0x50/0xac [ssb] >> [ 40.324152] [eec2fdb0] [c0214518] driver_probe_device+0xb8/0x1e8 >> [ 40.334541] [eec2fdd0] [c021487c] __driver_attach+0xf8/0x124 >> [ 40.344833] [eec2fdf0] [c0213674] bus_for_each_dev+0x58/0x94 >> [ 40.355100] [eec2fe20] [c0214328] driver_attach+0x24/0x34 >> [ 40.365321] [eec2fe30] [c0213af4] bus_add_driver+0x98/0x208 >> [ 40.375513] [eec2fe50] [c0214b44] driver_register+0x58/0xa0 >> [ 40.385771] [eec2fe60] [f20aff58] __ssb_driver_register+0x2c/0x3c [ssb] >> [ 40.396017] [eec2fe70] [f103e034] b43_init+0x34/0xe8 [b43] >> [ 40.406253] [eec2fe80] [c00587e4] sys_init_module+0x154/0x176c >> [ 40.416498] [eec2ff40] [c0012054] ret_from_syscall+0x0/0x38 >> >> I haven't found yet where the atomic is entered... >> >> johannes >> > > I have no idea where we enter atomic state. > I am using a slightly older kernel but also with the patch Larry > mentioned applied. This doesn't happen here. > Could you please try putting an WARN_ON(in_atomic()) assertion into > b43_probe? Though, I'm pretty sure it won't trigger. > I'd rather say mac80211 is aquireing some spinlock in the > register_hw codepath. > > Larry, note that this is not related to the b43 LEDs code. > This assertion triggers at the place where we register the > mac80211 TX, RX and radio LED triggers. The place where b43 > initialized rfkill and leds is not in the b43_probe stage. I do not see this problem with my BCM4311/2 on x86_64 hardware. Larry - To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
