From: Alan Jenkins <sourcejedi.lkml@googlemail.com>
To: Corrado Zoccolo <czoccolo@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux acpi <linux-acpi@vger.kernel.org>
Subject: Re: "ACPI: EC: missing confirmations, switch off interrupt mode" wastes time on startup
Date: Thu, 26 Mar 2009 16:58:36 +0000 [thread overview]
Message-ID: <9b2b86520903260958r790e5459r553308311522e88f@mail.gmail.com> (raw)
In-Reply-To: <4e5e476b0903260847m1de3e976ne20279df359176cf@mail.gmail.com>
On 3/26/09, Corrado Zoccolo <czoccolo@gmail.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
next prev parent reply other threads:[~2009-03-26 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 15:47 Corrado Zoccolo
2009-03-26 16:58 ` Alan Jenkins [this message]
2009-03-26 21:54 ` Corrado Zoccolo
2009-03-27 10:10 ` Alan Jenkins
2009-04-29 0:36 ` Ryan Hope
2009-04-29 7:41 ` Corrado Zoccolo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b2b86520903260958r790e5459r553308311522e88f@mail.gmail.com \
--to=sourcejedi.lkml@googlemail.com \
--cc=czoccolo@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®