diff mbox

Oopses and ACPI problems (Linus 2.6.29-rc4)

Message ID 5030FDE2BC%linux@youmustbejoking.demon.co.uk (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Darren Salt Feb. 10, 2009, 7:16 p.m. UTC 
I demand that Corentin Chary may or may not have written...

> On Tue, Feb 10, 2009 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org>
> wrote:
[snip; long delay when initialising eeepc-laptop]
>>>> BIOS bug. There's an explicit delay in the eee bios for some reason, and
>>>> I haven't found any straightforward way to avoid it.
>>> BIOS bug or no, the fact remains that this is (AFAICS) a regression.
>> You don't get properly working hotkeys otherwise, to the best of my
>> recollection. There's an entry on the kernel bugzilla about this
>> somewhere.

> http://bugzilla.kernel.org/show_bug.cgi?id=12243
> If I understand things correctly, this was already the case before, but the
> kernel boot was slower, so we couldn't see that. If it's not the case,
> someone with a 901 should try bisecting (I only have a 701).

I have some timings...

From 2.6.28.4:
[    0.898903] eeepc: Eee PC Hotkey Driver
[    0.902414] eeepc: Hotkey init (getting ACPI bus status)
[    0.905913] eeepc: Hotkey init (init flags)
[    2.620193] eeepc: Hotkey init flags 0x41
[    2.626667] eeepc: Get control methods supported: 0x101713
[    2.630215] input: Asus EeePC extra buttons as /class/input/input4

From 2.6.29-rc4:

[    2.141971] eeepc: Eee PC Hotkey Driver
[    2.145325] eeepc: Hotkey init (getting ACPI bus status)
[    2.148555] eeepc: Hotkey init (init flags)
[    2.286445] usb 5-1: new full speed USB device using uhci_hcd and address 2
[... USB Bluetooth device; Elantech test ...]
[    2.780187] input: ETPS/2 Elantech Touchpad as /class/input/input5
[   28.088399] eeepc: Hotkey init flags 0x41
[   28.094880] eeepc: Get control methods supported: 0x101713
[   28.098425] input: Asus EeePC extra buttons as /class/input/input6

Config is as in my first posting in this thread; kernel logs are attached.
The following patch is applied:

Comments

Matthew Garrett Feb. 11, 2009, 2:03 a.m. UTC | #1 
On Tue, Feb 10, 2009 at 07:16:27PM +0000, Darren Salt wrote:

> From 2.6.28.4:
> [    0.898903] eeepc: Eee PC Hotkey Driver
> [    0.902414] eeepc: Hotkey init (getting ACPI bus status)
> [    0.905913] eeepc: Hotkey init (init flags)
> [    2.620193] eeepc: Hotkey init flags 0x41
> [    2.626667] eeepc: Get control methods supported: 0x101713
> [    2.630215] input: Asus EeePC extra buttons as /class/input/input4

So we see the expected BIOS bizarro pause there...

> From 2.6.29-rc4:
> 
> [    2.141971] eeepc: Eee PC Hotkey Driver
> [    2.145325] eeepc: Hotkey init (getting ACPI bus status)
> [    2.148555] eeepc: Hotkey init (init flags)
> [    2.286445] usb 5-1: new full speed USB device using uhci_hcd and address 2
> [... USB Bluetooth device; Elantech test ...]
> [    2.780187] input: ETPS/2 Elantech Touchpad as /class/input/input5
> [   28.088399] eeepc: Hotkey init flags 0x41
> [   28.094880] eeepc: Get control methods supported: 0x101713
> [   28.098425] input: Asus EeePC extra buttons as /class/input/input6

And a rather more upsetting 26 second pause here. Yeah, ok, that's 
clearly a regression. I don't see any obvious way that it's an 
eeepc-laptop bug, though...
diff mbox

Patch

--- ./drivers/platform/x86/eeepc-laptop.c~	2009-02-10 16:40:18.000000000 +0000
+++ ./drivers/platform/x86/eeepc-laptop.c	2009-02-10 16:40:18.000000000 +0000
@@ -452,10 +452,15 @@ 
 	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
 	int result;
 
+	printk(EEEPC_NOTICE "Hotkey init (getting ACPI bus status)\n");
 	result = acpi_bus_get_status(ehotk->device);
 	if (result)
+	{
+		printk(EEEPC_ERR "Hotkey init aborted (%d)\n", result);
 		return result;
+	}
 	if (ehotk->device->status.present) {
+		printk(EEEPC_NOTICE "Hotkey init (init flags)\n");
 		if (write_acpi_int(ehotk->handle, "INIT", ehotk->init_flag,
 				    &buffer)) {
 			printk(EEEPC_ERR "Hotkey initialization failed\n");