Re: [RFT v9] rfkill: rewrite

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Wed, May 13, 2009 at 7:38 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-05-13 at 15:36 +0100, Alan Jenkins wrote:
>
>> >> <http://picasaweb.google.com/sourcejedi.lkml/Screenshots#53349368=
57267342674>
>> >>
>> >> The kernel then hangs later on in the boot process. =C2=A0It resp=
onds to
>> >> SysRq, but does not echo normal keypresses. =C2=A0SysRq+P shows t=
hat the
>> >> kernel is in the idle task. =C2=A0I left it for three minutes, bu=
t I didn't
>> >> get any trace from the hung task detector or soft lockup detector=
=2E
>> >>
>> >> At first I thought it must be a problem with wireless-testing.
>> >> However, it went away when I eventually tried un-applying the rfk=
ill
>> >> rewrite patch.
>> >
>> > Confusing, but I think the stacktrace is just bogus. Can you recom=
pile
>> > 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-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html