Date: Mon, 2 Apr 2007 23:17:15 +0200 From: ted@tednet.nl (Ted Lindgreen) To: freebsd-current@freebsd.org Subject: Acer 3623 with acpi version 20070320 Message-ID: <200704022117.l32LHFUt079690@omval.tednet.nl>
next in thread | raw e-mail | index | archive | help
Until revision 1.68 of acpi_ec.c ACPI worked on my Acer 3623 laptop, although lots of AE_NO_HARDWARE_RESPONSE messages were produced. I used a custom DSDT file, and a few patches to suppress the error messages. Starting with revision 1.69 of acpi_ec.c things like battery status stopped working. The import of 20070320 made no change. I found that the Acer does not like the EC_GET_CSR in EcWaitEvent to happen too quickly after an EC_SET_DATA or EC_SET_CSR command. Polling repeatedly makes thing worse as I found out playing with the tunables debug.acpi.ec.poll_time and debug.acpi.ec.timeout: the system freezes while slowly spitting out AE_NO_HARDWARE_RESPONSE messages. What did improve things was to insert a delay before EC_GET_CSR in EcWaitEvent. There is already code to do that, but it is disabled by #if 0 and the delay is coupled to EC_POLL_DELAY. Playing with a tunable delay here showed that with AcpiOsStall( 2200 ); the number of AE_NO_HARDWARE_RESPONSE messages started dropping. With 2300 us delay these messages occur only occasionally, and battery-status works again. With 2500 us delay there are no more error messages and everything works fine. I have debug.acpi.ec.poll_time and debug.acpi.ec.timeout back to default, and debug.acpi.ec.burst: 1. I also found that now I do not need the custom DSDT file anymore. regards, -- ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704022117.l32LHFUt079690>