linux-kernel - Re: "ACPI: EC: missing confirmations, switch off interrupt mode" wastes time on startup

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: <9b2b86520903260958r790e5459r553308311522e88f@mail.gmail.com>
Date:	Thu, 26 Mar 2009 16:58:36 +0000
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Corrado Zoccolo <czoccolo@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	linux acpi <linux-acpi@...r.kernel.org>
Subject: Re: "ACPI: EC: missing confirmations, switch off interrupt mode" 
	wastes time on startup

On 3/26/09, Corrado Zoccolo <czoccolo@...il.com> wrote:
> Hi,
> I found that on my netbook (acer aspire one 110), kernel boot time
> (kernel 2.6.29) is severely affected by the EC boot procedure, since
> it is first fooled by a spurious interrupt in thinking that interrupts
> work, and then gets a timeout waiting for an interrupt that never
> arrives:
> [    0.351161] calling  acpi_init+0x0/0x236 @ 1
> [    0.361052] ACPI: EC: Look up EC in DSDT
> [    0.367754] ACPI: BIOS _OSI(Linux) query ignored
> [    0.368984] ACPI: EC: non-query interrupt received, switching to
> interrupt mode
> [    0.860013] ACPI: EC: missing confirmations, switch off interrupt mode.
> [    0.866062] ACPI: Interpreter enabled
>
> There is a bug report for this issue
> http://bugzilla.kernel.org/show_bug.cgi?id=12001 ,  marked as fixed on
> an old kernel, but I'm still getting it with 2.6.29 (maybe my
> controller is flaky?), so I'm looking for a workaround: is there a way
> to force the ACPI using polling?

[CC linux-acpi]

Thanks for reporting this bug / issue.  Your hardware is probably
defective by design - that is, it doesn't follow the ACPI spec.  But
we can't blame users for that :-).

I take it this isn't a regression, i.e. if you've tried earlier
kernels, it's never worked any better?

You say this is a severe delay - but your logs show 0.5 seconds only,
is that right?  Just to get it clear.

Currently there is no option to force polling, sorry.  I'm _guessing_
this was a deliberate omission.  But I can sympathise that even 0.5s
boot delay is bad on a netbook.

Feel free to create a new bugzilla entry.  You can attach the full
output of dmesg, but acpidump is probably not required.  What would be
really helpful is if you could file on bugzilla, and attach a full
debug trace.  I.e. as well as the normal dmesg, attach the dmesg
output after recompiling with this change:

drivers/acpi/ec.c:
29: /* Uncomment next line to get verbose printout */
30: /* #define DEBUG */

change to

30: #define DEBUG

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