Date: Sun, 01 Oct 2006 14:22:36 -0700 From: Nate Lawson <nate@root.org> To: Ariff Abdullah <ariff@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, Cy Schubert <Cy.Schubert@spqr.komquats.com> Subject: Re: Acer Aspire 3620 Message-ID: <4520319C.2060000@root.org> In-Reply-To: <20060929234407.7d41e633.ariff@FreeBSD.org> References: <20060929124612.GC4945@poupinou.org> <20060929133747.78185.qmail@web27814.mail.ukl.yahoo.com> <20060929151704.GD4945@poupinou.org> <20060929234407.7d41e633.ariff@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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). 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? -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4520319C.2060000>