Acer Aspire 3620

[Cy Schubert]

In message <20061002064501.45105b84.ariff at FreeBSD.org>, Ariff Abdullah 
writes:
> --Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e
> Content-Type: text/plain; charset=US-ASCII
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> 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.
> > >=20
> >=20
> > The patch doesn't do what it claims to do.  First of all, burst mode
> >=20
> > does not work right on some systems, which is why I didn't complete=20
> > 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).
> >=20
> ... 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.=20
> > The default is 10  microseconds.  I'd be interested in seeing what
> > other values also work  (i.e. 50 us?  100 us?)
> >=20
> > What about not applying the patch and just increasing the overall=20
> > 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?
> >=20
> 
> 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=20
>      * to detect completion of the last command.
>      */
> +#if 0
>     for (i =3D 0; i < 1000 / EC_POLL_DELAY; i++) {
> 	EcStatus =3D EC_GET_CSR(sc);
> 	if (EVENT_READY(Event, EcStatus)) {
> 	    Status =3D AE_OK;
> 	    break;
> 	}
> 	AcpiOsStall(EC_POLL_DELAY);
>     }
> +#endif
>     period =3D i * EC_POLL_DELAY;

Indeed you will have no more messages and you will not have any way of knowing how much charge your battery has remaining (or the temperature of your motherboard for that matter).

My patch in PR/98171 solved my Acer Aspire 3623NWXMi ACPI embedded controller issues. All the patch does is provide some kernel tunables for variables already in the kernel to allow the user to tune (play with) the variables until the messages either stop or are reduced to a tolerable level. The root cause of the messages is a slow embedded controller in the Acer 3620 series laptops, not to mention broken ACPI. My patch allows you to reduce the rate at which acpi_ec.c polls the embedded controller allowing it to slowly recover from the last request made by acpi_ec.c to it. The embedded controller in the Acer 3620 (I have a 3623NWXMi) is unbelievably slow. I reduced the poll interval for my laptop to 1000 ms. The messages are gone, except for one or two thermal zone messages, and bettery level is what the EC reports to FreeBSD and this corresponds to what XP tells me too.

The reason the patch doesn't work for some people is that they fail to add the following to /boot/loader.conf:

 #hw.acpi.ec.poll_timeout=100
 #hw.acpi.ec.poll_delay=10
 hw.acpi.ec.poll_delay=1000
 # hw.acpi.ec.burst=1

I commented out the values I do not use. The hw.acpi.ec.poll_timeout is default at 100 ms. The hw.acpi.ec.poll_delay is default at 10 ms. I set mine to 1000 ms (1 second). The hw.acpi.ec.burst is default 0. Nate has said that this doesn't always work. However if you search the various Linux archives, the Linux ACPI folks tend to use burst mode. In addition to this, they also replace the DSDT. You can find replacement DSDT code at acpi.sourceforge.net, compile it using iasl and load it using acpi_dsdt_load="filename" in /boot/loader.conf. I've tried the 3624NWXMi ACPI code in my 3623 with limited success.

The other thing you might want to try is to disassemble your DSDT, fix the bugs in it and recompile it using iasl. I tried this as well until I realised that the root casue of the 3620 EC problems was slow embedded controller hardware, hence the patch.

If you use my patch, a bit of tinkering will be required or you could use a sledge hammer like I did and set the poll interval to 1 full second. I doubt the battery charge or the temperature would change that much in the space of a second.



-- 
Cheers,
Cy Schubert <Cy.Schubert at komquats.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

			e**(i*pi)+1=0