Acer Aspire 3620

[Ariff Abdullah]

On Sun, 01 Oct 2006 14:22:36 -0700
Nate Lawson <nate at root.org> wrote:
> 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).
> 
... which, I agree.

> 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?
> 

I've just decided to concentrate on this issue. Surpisingly, with just
a little hack, everything works smoothly (no more annoying messages,
battery status works):

--- acpi_ec.c

    /*
     * Poll the EC status register for up to 1 ms in chunks of 10 us 
     * to detect completion of the last command.
     */
+#if 0
    for (i = 0; i < 1000 / EC_POLL_DELAY; i++) {
	EcStatus = EC_GET_CSR(sc);
	if (EVENT_READY(Event, EcStatus)) {
	    Status = AE_OK;
	    break;
	}
	AcpiOsStall(EC_POLL_DELAY);
    }
+#endif
    period = i * EC_POLL_DELAY;
---

and that what makes it entering ec_poll_timeout loop below that.


--
Ariff Abdullah
FreeBSD

... Recording in stereo is obviously too advanced
    and confusing for us idiot ***** users :P ........
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20061001/e997b4d8/attachment.pgp