On Wed, May 13, 2009 at 7:38 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2009-05-13 at 15:36 +0100, Alan Jenkins wrote: > >> >> <http://picasaweb.google.com/sourcejedi.lkml/Screenshots#5334936857267342674> >> >> >> >> The kernel then hangs later on in the boot process. It responds to >> >> SysRq, but does not echo normal keypresses. SysRq+P shows that the >> >> kernel is in the idle task. I left it for three minutes, but I didn't >> >> get any trace from the hung task detector or soft lockup detector. >> >> >> >> At first I thought it must be a problem with wireless-testing. >> >> However, it went away when I eventually tried un-applying the rfkill >> >> rewrite patch. >> > >> > Confusing, but I think the stacktrace is just bogus. Can you recompile >> > your kernel with CONFIG_FRAME_POINTER please? >> >> Nope, cos it's already enabled :-). > > Damn, I had hoped to get relevant information. I really don't see how > rfkill could cause a problem in regulatory code, let's ask Luis. I'd review the code but its easier to just ask for now -- do you use the global workqueue ? Anyway -- the more jammed up the global workqueue is the more likely it is that last_request will not be populated before a driver comes around with they custom reg request. The stupid solution is to check for last_request. The right solutions it to flush the global workqueue which I have just addressed. Mind you I think its now worth considering adding our own workqueue to cfg80211 so we don't have to flush every damn thing on the global workqueue on the core initialization but I figured that can be done in a separate series as we need to address stable as well. Luis -- 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
