linux-kernel - Re: eeepc_hotkey adds 25s to boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <71cd59b00907281308m3778bbaex2e4f4ba45f7014ef@mail.gmail.com>
Date:	Tue, 28 Jul 2009 22:08:46 +0200
From:	Corentin Chary <corentin.chary@...il.com>
To:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
Cc:	Luciano Rocha <luciano@...otux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: eeepc_hotkey adds 25s to boot

On Tue, Jul 28, 2009 at 9:19 PM, Alan
Jenkins<sourcejedi.lkml@...glemail.com> wrote:
> On 7/28/09, Luciano Rocha <luciano@...otux.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@...otux.com>
>>> > wrote:
>>> > > As subject says, loading the eeepc_hotkeys driver or including it
>>> > > inside
>>> > > the kernel adds 25s to the boot process:
>>> > > [   13.990092] eeepc: Eee PC Hotkey Driver
>>> > > [   39.560645] eeepc: Hotkey init flags 0x41
>>> > > [   39.566131] eeepc: Get control methods supported: 0x101713
>>> > > [   39.566418] input: Asus EeePC extra buttons as ...
>>> > >
>>> > > Kernel is 2.6.30.3 (with tuxonice).
>>> > >
>>> > > Config and full dmesg follows.
>>> > >
>>> > > 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).
>
> Alan
>

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.
But I believe that the rfkill device can work without the notifier
(which is an acpi notifier).



-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/