Date: Mon, 2 Oct 2006 22:49:45 +0800 From: Ariff Abdullah <ariff@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@FreeBSD.org, Cy.Schubert@spqr.komquats.com Subject: Re: Acer Aspire 3620 Message-ID: <20061002224945.4cb4c605.ariff@FreeBSD.org> In-Reply-To: <4520AA88.2080908@root.org> References: <200610012328.k91NSJmG006722@cwsys.cwsent.com> <4520AA88.2080908@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 01 Oct 2006 22:58:32 -0700 Nate Lawson <nate@root.org> wrote: >=20 > He says that battery status works after his patch. This still needs > This "battery status works" probably need a reintepretation. First, let me remind you guys about this: http://lists.freebsd.org/mailman/htdig/freebsd-acpi/2006-January/002416.html I have 3 laptops (not mine), and luckily each behaves differently 1) Acer Ferrari 4k Here, everything works great after patching the dsdt to resolve "Z00N" issue. Battery status works perfect and report _BOTH_ "Remaining capacity:" _and_ "Remaining time". # sysctl hw.acpi.battery hw.acpi.battery.life: 98 <- I guess % of capacity hw.acpi.battery.time: 120 <- minutes hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 2) Compaq Presario M2000 Things becoming interesting here. At first, I thought there is no way to find out the battery status just because both sysctl hw.acpi.battery and acpiconf return invalid value/error. Digging through the sources, and I realize that both of them set a strict requirement for battery status to return proper "Remaining time" and simply bail out just because it can't find any. Nevertheless, my patch for acpiconf.c is at least let it be more forgiving about this. Even on Windows/Linux, they do not try hard to calculate "Remaining Time" if it seems impossible and just satisfied with "Remaining Capacity". # sysctl hw.acpi.battery hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 3) Compaq Presario V3000 Simmilar problem with #2. Solved after the acpi_ec.c hack. Strange thing is, even this laptop does not support "Remaining time", yet the battery status works even without patching acpiconf.c # sysctl hw.acpi.battery hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 There is indeed a considerable delay while running sysctl caused by tsleep() loop, which makes the battery status works. Something to do with _BIF or _BST, I guess. > more isolation. Does increasing EC_POLL_DELAY from 10 to 100 help?=20 > Does moving AcpiOsStall() before the first read (EC_GET_CSR) work? >=20 Doesn't help. > > 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. > >=20 > > The reason the patch doesn't work for some people is that they > > fail to add the following to /boot/loader.conf: > >=20 > > #hw.acpi.ec.poll_timeout=3D100 > > #hw.acpi.ec.poll_delay=3D10 > > hw.acpi.ec.poll_delay=3D1000 > > # hw.acpi.ec.burst=3D1 > >=20 > > 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=3D"filename" in > > /boot/loader.conf. I've tried the 3624NWXMi ACPI code in my 3623 > > with limited success. >=20 > 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. >=20 > I'm interested in one or more of you trying to isolate this more.=20 > 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? >=20 I'm a bit busy with snd_hda(4), but I'll tag along. > Thanks, > --=20 > Nate >=20 -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFIScNlr+deMUwTNoRAmfVAJkBT5ebFtqqDXDX0ITY8zb/I3CGjgCg0+Mg B3x0dfxGUtwTKnnBofl2u9A= =iSLT -----END PGP SIGNATURE----- --Signature=_Mon__2_Oct_2006_22_49_45_+0800_Bx/WP916d3TkEWLi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061002224945.4cb4c605.ariff>