From owner-freebsd-current@FreeBSD.ORG Wed Sep 26 09:26:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF60916A419 for ; Wed, 26 Sep 2007 09:26:30 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (omval.tednet.nl [IPv6:2001:7b8:206:1:200:39ff:fe59:b187]) by mx1.freebsd.org (Postfix) with ESMTP id 77A5113C45D for ; Wed, 26 Sep 2007 09:26:30 +0000 (UTC) (envelope-from ted@omval.tednet.nl) Received: from omval.tednet.nl (localhost [127.0.0.1]) by omval.tednet.nl (8.14.1/8.14.1) with ESMTP id l8Q9QPMM063377; Wed, 26 Sep 2007 11:26:25 +0200 (CEST) (envelope-from ted@omval.tednet.nl) Received: (from ted@localhost) by omval.tednet.nl (8.14.1/8.14.1/Submit) id l8Q9QPkG063376; Wed, 26 Sep 2007 11:26:25 +0200 (CEST) (envelope-from ted) Message-Id: <200709260926.l8Q9QPkG063376@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Wed, 26 Sep 2007 11:26:24 +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=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_40 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on omval.tednet.nl X-Mailman-Approved-At: Wed, 26 Sep 2007 12:34:24 +0000 Cc: Ted Lindgreen Subject: New acpi_ec.c 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: Wed, 26 Sep 2007 09:26:30 -0000 Hi, The file /usr/src/sys/dev/acpica/acpi_ec.c has been updated recently. This broke my patch (about which I have posted earlier this year (around March) to let my Acer 3623 behave properly. I append a new patch, which can be applied to the new acpi_ec.c. To recap the problem and the hack that I found to fix it: - It appears that the EC of my Acer 3623 does not like to be polled for status to soon after writing a command to it. - The error message AE_NO_HARDWARE_RESPONSE is output in enormous amounts, and commands like apm(8) fail. - With a delay of 2500 the amount of AE_NO_HARDWARE_RESPONSE messages drops significantly, and apm(8) works. - With a delay of 3000 no more AE_NO_HARDWARE_RESPONSE messages appear, and everything works flawlessly. regards, -- ted PS. the patch: In /boot/loader.conf I have: debug.acpi.ec.burst="1" debug.acpi.ec.waitbeforepoll="3000" and the change in acpi_ec.c: --- acpi_ec.c 2007-09-26 11:18:27.000000000 +0200 +++ acpi_ec.c.org 2007-09-24 18:59:06.000000000 +0200 @@ -193,10 +193,6 @@ TUNABLE_INT("debug.acpi.ec.timeout", &ec_timeout); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, timeout, CTLFLAG_RW, &ec_timeout, EC_TIMEOUT, "Total time spent waiting for a response (poll+sleep)"); -static int ec_waitbeforepoll = 0; -TUNABLE_INT("debug.acpi.ec.waitbeforepoll", &ec_waitbeforepoll); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, waitbeforepoll, CTLFLAG_RW, &ec_waitbeforepoll, - 0, "Wait before starting to poll"); static ACPI_STATUS EcLock(struct acpi_ec_softc *sc) @@ -806,10 +802,6 @@ if (cold || rebooting || ec_polled_mode) { static int once; - /* Some EC's just need enough time before they can be polled */ - if (ec_waitbeforepoll > 0) - AcpiOsStall(ec_waitbeforepoll); - else { if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { if (!once) { device_printf(sc->ec_dev, @@ -818,7 +810,6 @@ } AcpiOsStall(10); } - } } /* Wait for event by polling or GPE (interrupt). */