Messages in this thread | | | Date | Wed, 29 Jul 2009 12:21:13 +0200 | Subject | Re: eeepc_hotkey rmmod issues | From | Corentin Chary <> |
| |
On Wed, Jul 29, 2009 at 12:01 PM, Alan Jenkins<sourcejedi.lkml@googlemail.com> wrote: > On 7/28/09, Corentin Chary <corentin.chary@gmail.com> wrote: >> On Tue, Jul 28, 2009 at 9:19 PM, Alan >> Jenkins<sourcejedi.lkml@googlemail.com> wrote: >>> On 7/28/09, Luciano Rocha <luciano@eurotux.com> wrote: >>>> On Tue, Jul 28, 2009 at 05:50:26PM +0100, Luciano Rocha wrote: >>>>> On Mon, Jul 27, 2009 at 10:45:14PM +0300, Pekka Enberg wrote: >>>>> > (Adding Corentin to cc) >>>>> > >>>>> > On Mon, Jul 27, 2009 at 10:27 PM, Luciano Rocha<luciano@eurotux.com> >>>>> > wrote: >>>>> > > Also, a "rmmod eeepc_hotkeys" resulted in a kernel panic. If asked, >>>>> > > I'll >>>>> > > try to replicate it. >>>>> > >>>>> > Yes, please. >>>>> >>>>> Hm, rebooted without i2c_i801, browsed some, then did a rmmod >>>>> eeepc_laptop: >>>>> ERROR!!! H2M_MAILBOX still hold by MCU. command fail >>>>> ERROR!!! H2M_MAILBOX still hold by MCU. command fail >>>>> >>>>> Two equal lines, yes. What does it mean? >>>> >>>> Nevermind, the wireless driver didn't like that the hardware >>>> disappeared. >>> >>> Thanks for the bug report anyway :-). >>> >>> So presumably this is what caused your oops earlier. I assume the >>> wireless toggle button doesn't normally cause any errors. >>> >>> The new rfkill core in 2.6.31 should avoid triggering this bug. The >>> new core won't disable the wireless when the eeepc-laptop module is >>> removed. >>> >>> But we should still fix the underlying problem. It sounds like >>> there's a narrow danger window on module unload. And it's still there >>> in 2.6.31-rc4: >>> >>> 1019 static void eeepc_rfkill_exit(void) >>> 1020 { >>> 1021 eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P6"); >>> 1022 eeepc_unregister_rfkill_notifier("\\_SB.PCI0.P0P7"); >>> 1023 if (ehotk->wlan_rfkill) >>> 1024 rfkill_unregister(ehotk->wlan_rfkill); >>> >>> Really we need to perform these unregistrations "at the same time". >>> The rfkill device relies on the notifier, but the notifier callback >>> also uses the rfkill device. I guess we will need to a mutex to >>> synchronize unregistration (and registration). >> >> I think 2.6.31 is ok, > >> In 2.6.30, we called eeepc_unregister_rfkill_notifier after >> rfkill_free, which was an error because >> the notifier callback uses the rfkill device. > > Ok. I don't see how that causes Luciano's errors. So I guess he was > right to blame the wireless driver.
If he was using 2.6.30, then : eeepc_unregister_rfkill_notifier() was called after rfkill_unregister() And the callback was still registered after rfkill_unregister(), *Ooops*
In 2.6.31 we first unregister the callback, and then rfkill, so rmmod should works.
>> But I believe that the rfkill device can work without the notifier >> (which is an acpi notifier). > > I don't think it can. > > If the rfkill device is set to "soft blocked", the pci device is > removed. If the acpi notifier is not called, the pci driver (e.g. > ath5k) won't realise the device is gone. The network device (e.g. > wlan0) will remain present, but it won't work.
Hum, there is a misunderstanding here. What I mean is : I think eeepc_rfkill_exit(void) is ok in 2.6.31 (Luciano used 2.6.30).
And eeepc_rfkill_exit() is only called on rmmod eeepc-laptop
Commit 7de39389d8f61aa517ce2a8b4d925acc62696ae5 did a lot of change in rfkill code.
> So I believe there's a circular dependency which we need to resolve. > Would you like me to write a patch for it?
It's possible that I miss the issue here, so go ahead :)
-- Corentin Chary http://xf.iksaif.net - http://uffs.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |