From owner-freebsd-current@FreeBSD.ORG Mon Apr 2 22:27:45 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5D16A406 for ; Mon, 2 Apr 2007 22:27:45 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (omval.tednet.nl [213.154.224.17]) by mx1.freebsd.org (Postfix) with ESMTP id A260213C459 for ; Mon, 2 Apr 2007 22:27:44 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (localhost [127.0.0.1]) by omval.tednet.nl (8.13.8/8.13.8) with ESMTP id l32LHFWi079695 for ; Mon, 2 Apr 2007 23:17:15 +0200 (CEST) (envelope-from ted@omval.tednet.nl) Received: (from ted@localhost) by omval.tednet.nl (8.13.8/8.13.8/Submit) id l32LHFUt079690 for freebsd-current@freebsd.org; Mon, 2 Apr 2007 23:17:15 +0200 (CEST) (envelope-from ted) Message-Id: <200704022117.l32LHFUt079690@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Mon, 2 Apr 2007 23:17:15 +0200 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: freebsd-current@freebsd.org X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, SUBJ_HAS_UNIQ_ID autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on omval.tednet.nl X-Mailman-Approved-At: Tue, 03 Apr 2007 02:13:49 +0000 Subject: Acer 3623 with acpi version 20070320 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 22:27:45 -0000 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