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?
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
On 3/26/09, Corrado Zoccolo <[email protected]> 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
On Thu, Mar 26, 2009 at 5:58 PM, Alan Jenkins
<[email protected]> wrote:
> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>
> [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?
This is new hardware, and 2.6.29 is the first kernel I installed, so I
can't say.
>
> You say this is a severe delay - but your logs show 0.5 seconds only,
> is that right? Just to get it clear.
>
Right, but Arjan showed that 1s boot time for kernel is possible, so
0.5s is quite severe respect to this :).
I'm still way far from 1s, though, due to an other issue that wastes
>1s, i.e. tsc clocksource unstable.
> 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.
>
Yes. Do you think that changing olpc_ec_timeout kernel parameter may
help in getting the timeout sooner?
> 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:
>
bug: http://bugzilla.kernel.org/show_bug.cgi?id=12949
full debug dmesg: http://bugzilla.kernel.org/attachment.cgi?id=20695
Thanks,
Corrado
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
> On Thu, Mar 26, 2009 at 5:58 PM, Alan Jenkins
> <[email protected]> wrote:
>> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>>
>> 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.
>>
> Yes. Do you think that changing olpc_ec_timeout kernel parameter may
> help in getting the timeout sooner?
>
No, that's something different. There's no boot option to change the timeout.
>> 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:
>>
>
> bug: http://bugzilla.kernel.org/show_bug.cgi?id=12949
> full debug dmesg: http://bugzilla.kernel.org/attachment.cgi?id=20695
Great.
I am getting this on my Acer also...
-Ryan
On 3/27/09, Alan Jenkins <[email protected]> wrote:
> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>> On Thu, Mar 26, 2009 at 5:58 PM, Alan Jenkins
>> <[email protected]> wrote:
>>> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>>>
>>> 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.
>>>
>> Yes. Do you think that changing olpc_ec_timeout kernel parameter may
>> help in getting the timeout sooner?
>>
>
> No, that's something different. There's no boot option to change the
> timeout.
>
>>> 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:
>>>
>>
>> bug: http://bugzilla.kernel.org/show_bug.cgi?id=12949
>> full debug dmesg: http://bugzilla.kernel.org/attachment.cgi?id=20695
>
> Great.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Alexey has provided a patch for this. Please look at:
http://bugzilla.kernel.org/show_bug.cgi?id=12949
Corrado
On Wed, Apr 29, 2009 at 2:36 AM, Ryan Hope <[email protected]> wrote:
> I am getting this on my Acer also...
>
> -Ryan
>
> On 3/27/09, Alan Jenkins <[email protected]> wrote:
>> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>>> On Thu, Mar 26, 2009 at 5:58 PM, Alan Jenkins
>>> <[email protected]> wrote:
>>>> On 3/26/09, Corrado Zoccolo <[email protected]> wrote:
>>>>
>>>> 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.
>>>>
>>> Yes. Do you think that changing olpc_ec_timeout kernel parameter may
>>> help in getting the timeout sooner?
>>>
>>
>> No, that's something different. There's no boot option to change the
>> timeout.
>>
>>>> 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:
>>>>
>>>
>>> bug: http://bugzilla.kernel.org/show_bug.cgi?id=12949
>>> full debug dmesg: http://bugzilla.kernel.org/attachment.cgi?id=20695
>>
>> Great.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
__________________________________________________________________________
dott. Corrado Zoccolo mailto:[email protected]
PhD - Department of Computer Science - University of Pisa, Italy
--------------------------------------------------------------------------
The self-confidence of a warrior is not the self-confidence of the average
man. The average man seeks certainty in the eyes of the onlooker and calls
that self-confidence. The warrior seeks impeccability in his own eyes and
calls that humbleness.
Tales of Power - C. Castaneda