Date: Mon, 2 Oct 2006 06:45:01 +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: <20061002064501.45105b84.ariff@FreeBSD.org> In-Reply-To: <4520319C.2060000@root.org> References: <20060929124612.GC4945@poupinou.org> <20060929133747.78185.qmail@web27814.mail.ukl.yahoo.com> <20060929151704.GD4945@poupinou.org> <20060929234407.7d41e633.ariff@FreeBSD.org> <4520319C.2060000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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;
---
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 ........
--Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFFIETwlr+deMUwTNoRAv2IAKCnNVOJm4ESO69WZqz5hGrNjh/eFACeOuaF
va/p75ZbSkWztC6BFEGIGQs=
=K1Ub
-----END PGP SIGNATURE-----
--Signature=_Mon__2_Oct_2006_06_45_02_+0800_g9nnw26DSrC_2d3e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061002064501.45105b84.ariff>