Acer Aspire 3620

[Nate Lawson]

Ariff Abdullah wrote:
> On Fri, 29 Sep 2006 17:17:04 +0200
> Bruno Ducrot <ducrot at poupinou.org> wrote:
>> I'm a little bit annoyed by those errors:
>>
>> ACPI-0501: *** Error: Handler for [EmbeddedControl] returned
>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution
>> failed [\\_SB_.PCI0.LPCB.EC0_.GBST] (Node 0xc325fbc0),
>> AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution
>> failed [\\_SB_.PCI0.LPCB.EC0_.BAT0._BST] (Node 0xc325fa80),
>> AE_NO_HARDWARE_RESPONSE
>>
>> I think this will break support for battery and maybe thermal zone
>> and likely other stuff (though I'm not sure exacly what).
>>
>>
> I guess kern/98171 is worth an attention. That at least fix my
> problem on Compaq V3000.
> 

The patch doesn't do what it claims to do.  First of all, burst mode 
does not work right on some systems, which is why I didn't complete 
implementing it.  Even on systems where it works, it seems slower than 
the default method.  So the parts related to burst mode should not be 
applied unless full support for burst mode is being implemented (i.e. 
handling hardware-initiated exits from burst mode instead of ignoring them).

The part that probably has the actual effect is increasing the time that 
the system waits for a response.  (Try this independent of the burst 
mode changes to verify).  EC_POLL_DELAY is the time between reads of the 
status register while waiting for a response.  But 1 second is a 
horrible amount of time to have the CPU busy-looping.  The default is 10 
microseconds.  I'd be interested in seeing what other values also work 
(i.e. 50 us?  100 us?)

What about not applying the patch and just increasing the overall 
timeout period?  Set the tunable hw.acpi.ec.poll_timeout to the total 
number of milliseconds (ms) to wait.  Does that fix it?  For what values?

-- 
Nate