Re: [RFT v9] rfkill: rewrite

Alan Jenkins
2009-05-14T09:02:53Z

On 5/13/09, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Tue, May 12, 2009 at 7:09 AM, Alan Jenkins
> <sourcejedi.lkml@googlemail.com> wrote:
>> On 5/11/09, Johannes Berg <johannes@sipsolutions.net> wrote:
>>> This patch completely rewrites the rfkill core to address
>>> the following deficiencies:
>>
>> Btw, git-apply nitpicks on your whitespace
>>
>> rfkill-rewrite.patch:4335: space before tab in indent.
>> mutex_unlock(&rfkill_global_mutex);
>> warning: 1 line adds whitespace errors.
>>
>>
>> I tested on todays wireless-testing, aka v2.6.30-rc5-23297-gbf2c6a3.
>> Somehow, it triggers an OOPS
>>
>> Function: req_reg_info_regd
>> Process: modprobe
>>
>> Call trace:
>> wiphy_apply_custom_regulatory
>> ath5k_regd_init
>> ath5k_reg_notifier
>> ath5k_pci_probe
>> ...
>>
>> Photo:
>> <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.
>
> I think my new 4 patches should address this and it'd be great to hear
> your tests as you can reproduce easily. We are able to see something
> like this but only after 3 hours of testing. Since it seems you might
> be able to reproduce quickly it would help.

Glad to be of service :-).

I applied your four patches on top of my current tree
(wireless-testing+rfkill rewrite), and it fixed the OOPS.

As a sanity check, I tried un-applying patch 4/4 (cfg80211: fix race
between core hint and driver's custom apply), since that looked like
the fix I was interested in. Un-applying this fix caused the OOPS to
reappear.

Thanks!
Alan