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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9b2b86520907281219g4d804f05v46af85fdb0690609@mail.gmail.com>
Date:	Tue, 28 Jul 2009 20:19:05 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Luciano Rocha <luciano@...otux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org, corentincj@...aif.net
Subject: Re: eeepc_hotkey adds 25s to boot

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
--
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/