Date: Sun, 01 Oct 2006 22:58:32 -0700 From: Nate Lawson <nate@root.org> To: Cy Schubert <Cy.Schubert@spqr.komquats.com> Cc: freebsd-acpi@FreeBSD.org, Ariff Abdullah <ariff@FreeBSD.org> Subject: Re: Acer Aspire 3620 Message-ID: <4520AA88.2080908@root.org> In-Reply-To: <200610012328.k91NSJmG006722@cwsys.cwsent.com> References: <200610012328.k91NSJmG006722@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Cy Schubert wrote:
> In message <20061002064501.45105b84.ariff@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@root.org> wrote:
>>> Ariff Abdullah wrote:
>>>> On Fri, 29 Sep 2006 17:17:04 +0200
>>>> Bruno Ducrot <ducrot@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).
He says that battery status works after his patch. This still needs
more isolation. Does increasing EC_POLL_DELAY from 10 to 100 help?
Does moving AcpiOsStall() before the first read (EC_GET_CSR) work?
> 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.
Your ec_poll_delay (and EC_POLL_DELAY) is in units of microseconds (us),
not milliseconds (ms). The default poll delay is 10 microseconds
between reads of the command/status register. The default total timeout
(poll_timeout) is 100 milliseconds.
I'm interested in one or more of you trying to isolate this more. Is
the problem the first read (EC_GET_CSR) happening too quickly on some
systems? Or is it that polling every 10 microseconds is too often? At
what exact threshold does it start to work for your system?
Thanks,
--
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4520AA88.2080908>