From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 9 04:02:05 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0038D16A418 for ; Sun, 9 Sep 2007 04:02:04 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 5E65C13C458 for ; Sun, 9 Sep 2007 04:02:04 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1094244mue for ; Sat, 08 Sep 2007 21:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=mvM2/IZoRmls9qoB/EAPFI4250By0uQNbtceXkAKRk8=; b=RxD+sMgEKomveZ7l2gpBrwfZUMV3KycRRfQItTnTlZZClI8BLOtYUxfQjjb3C599HFFNYqIIwozgiL7/pxuT9vixlvG9gAo+rhoaJF80ltg8/87qay8tr5S+pIUHKwAZHHoql/vxKdqhEI9HbxDYvZNifn7VrUL4a3XWe7O7nT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U9cA0ZrPs7UijGRULROv+gPHL3+86Lhx2MQbAzGAJLU/y0e5dIrkSJvc/Fyiw0f1T7Y9vIlw73OXtkq/4IeRAzMH15tHbQXYOZ+6Aztl5E8pd3QFcqWGGhjL5sbZnWJMKdOlhBHcMTy0Z8eYeGTAiIltRwhnKGjR0lRtnqwBxl4= Received: by 10.86.76.16 with SMTP id y16mr2666161fga.1189310522914; Sat, 08 Sep 2007 21:02:02 -0700 (PDT) Received: by 10.86.86.19 with HTTP; Sat, 8 Sep 2007 21:02:02 -0700 (PDT) Message-ID: <325305250709082102m45a5dbfpced3291a2a86f372@mail.gmail.com> Date: Sun, 9 Sep 2007 08:02:02 +0400 From: Denis To: "Nate Lawson" , freebsd-acpi@freebsd.org In-Reply-To: <46E0784D.6030600@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E0784D.6030600@root.org> Cc: Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 04:02:05 -0000 Sorry for the delay in answer. Nope, this patch didn't help me. If I boot with ACPI enabled (compaq nc6220 laptop) I get the same error: --- ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire Mutex [0] [20070320] ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C265] (Node 0xc2e3fbe0), AE_TIME ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME acpi_tz0: error fetching current temperature -- AE_TIME ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] --- and have switch power off to reboot. Best regards, Denis. On 9/7/07, Nate Lawson wrote: > Denis wrote: > > I use FreeBSD 7.0 (FreeBSD MY.LAPTOP 7.0-CURRENT FreeBSD 7.0-CURRENT > > #0: Sat Sep 1 18:26:32 MSD 2007 > > root@MY.LAPTOP:/usr/obj/usr/src/sys/GENERIC i386) on my laptop - > > Compaq nc6220. > > And when I boot with ACPI enable after short period of time (about 0-3 > > minutes) I get next error on the console 0 (this message doesn't save > > in the log, I made photo and type from it): > > --- > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > Mutex [0] [20070320] > > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > Mutex [0] [20070320] > > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > > ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C265] > > (Node 0xc2e3fbe0), AE_TIME > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME > > acpi_tz0: error fetching current temperature -- AE_TIME > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > > --- > > > > After this error I cannot continue to work, the only way to reboot - > > to switch power off. > > Without ACPI it works fine. > > Try the patch I just posted. > > -Nate > From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 9 20:41:25 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15B1216A41A for ; Sun, 9 Sep 2007 20:41:25 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id BA98413C468 for ; Sun, 9 Sep 2007 20:41:24 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27135 invoked from network); 9 Sep 2007 20:41:23 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 9 Sep 2007 20:41:23 -0000 Message-ID: <46E45A6D.1010805@root.org> Date: Sun, 09 Sep 2007 13:41:17 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Kostik Belousov References: <46E0777A.8070901@root.org> <20070907133901.GL53667@deviant.kiev.zoral.com.ua> In-Reply-To: <20070907133901.GL53667@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------040800050701000906010408" Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:41:25 -0000 This is a multi-part message in MIME format. --------------040800050701000906010408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kostik Belousov wrote: > On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: >> I've done some major rework on the EC driver. This should help with >> various problems, including timeouts while checking battery status or >> temperature. The attached patches are for 6.x and 7.x. Please test and >> let me know if you get any new errors on dmesg or if it fixes things for >> you (especially HP/Compaq laptop owners). > Ok, I tryed it on Acer 2490-kind of laptop. I see no difference with the > patch, battery status seems to be reported correctly both before and after > applying it. > > The only thing I want to note is that reboot on the laptop is turned into > poweroff. You said in the followup to original letter that poweroff is > turned into reboot, I did not checked it; this is opposite. Please test this revised version. All it changes is forcing polling mode back on during reboot/shutdown. -Nate --------------040800050701000906010408 Content-Type: text/x-patch; name="ecng-6b.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6b.diff" --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 9 Sep 2007 20:35:53 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,7 +149,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,36 +186,46 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +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 ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); @@ -328,7 +235,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -369,7 +277,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -688,100 +598,92 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +727,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -850,149 +764,188 @@ if (ACPI_FAILURE(Status)) break; } - EcUnlock(sc); + return_ACPI_STATUS (Status); } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { + if (cold || rebooting || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; - if (count == 0) + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); + sc->ec_burstactive = FALSE; + } if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } @@ -1000,43 +953,50 @@ static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------040800050701000906010408 Content-Type: text/x-patch; name="ecng-7b.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7b.diff" --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 6 Sep 2007 22:23:52 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -248,7 +139,6 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; int ec_data_rid; struct resource *ec_data_res; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; 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 __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,25 +206,14 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } @@ -349,7 +225,8 @@ ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -390,7 +267,9 @@ * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -661,7 +539,6 @@ if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,52 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +645,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +714,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +757,94 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. For now, let's + * collect some stats about how many systems actually have this issue. */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { + if (cold || rebooting || ec_polled_mode) { + static int once; + EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; + if (!once && EVENT_READY(Event, EcStatus)) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; - } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); sc->ec_burstactive = FALSE; } if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); Status = AE_OK; break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time. + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + EcStatus = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(EcStatus & EC_FLAG_BURST_MODE)) { + CTR0(KTR_ACPI, "ec burst disabled in waitevent (sleep)"); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(Event, EcStatus)) { + CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); + Status = AE_OK; + break; + } + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +852,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +872,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +888,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +898,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,21 +917,20 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } @@ -1086,6 +942,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +961,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------040800050701000906010408-- From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 9 20:59:39 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B424116A46E for ; Sun, 9 Sep 2007 20:59:39 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4300713C49D for ; Sun, 9 Sep 2007 20:59:39 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 28150 invoked from network); 9 Sep 2007 20:59:40 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 9 Sep 2007 20:59:40 -0000 Message-ID: <46E45CFE.2010206@root.org> Date: Sun, 09 Sep 2007 13:52:14 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Denis References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E0784D.6030600@root.org> <325305250709082102m45a5dbfpced3291a2a86f372@mail.gmail.com> In-Reply-To: <325305250709082102m45a5dbfpced3291a2a86f372@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 20:59:39 -0000 Denis wrote: > Sorry for the delay in answer. > > Nope, this patch didn't help me. If I boot with ACPI enabled (compaq > nc6220 laptop) I get the same error: > > --- > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > Mutex [0] [20070320] > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > Mutex [0] [20070320] > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C265] > (Node 0xc2e3fbe0), AE_TIME > ACPI Error (psparse-0626): Method parse/execution failed > [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME > acpi_tz0: error fetching current temperature -- AE_TIME > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > --- > > and have switch power off to reboot. > > Best regards, Denis. Ok, thanks, this is a different problem. Jung-uk Kim has a patch that may help mutex behavior. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 9 21:16:28 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F281316A41B for ; Sun, 9 Sep 2007 21:16:28 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id B00C313C468 for ; Sun, 9 Sep 2007 21:16:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 29033 invoked from network); 9 Sep 2007 21:16:29 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 9 Sep 2007 21:16:29 -0000 Message-ID: <46E462A7.4080802@root.org> Date: Sun, 09 Sep 2007 14:16:23 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Mikael Ikivesi References: <46E0777A.8070901@root.org> <200709081054.14073.mikael.ikivesi@pp.inet.fi> In-Reply-To: <200709081054.14073.mikael.ikivesi@pp.inet.fi> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------050606020709050303060101" Cc: freebsd-acpi@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2007 21:16:29 -0000 This is a multi-part message in MIME format. --------------050606020709050303060101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mikael Ikivesi wrote: > Note still: If I try to suspend machine I get kernel panic. I dont know if it > was you patch or some other update, but before I got only messages and bounce > back to system without crashing. Because of the updates I cannot now access > the messages but if I remember correctly they were something about: > device physically ejected? and they had something to do with cardbus if I > remember correctly... > ...sorry for being so vague! > > > BUT about that panic I can be more precise :) > > > acpi_button0: sleep button pressed > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex ACPI global lock r = 0 (0xffffffff808ac4a0) locked > @ /usr/src/sys/dev/acpica/acpi.c:2222 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_warn() at witness_warn+0x248 > trap() at trap+0x25e > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff801d9cf4, rsp = 0xffffffff9ed4aa00, rbp = > 0xffffffff9ed4aa30 --- > acpi_AckSleepState() at acpi_AckSleepState+0x34 > devfs_ioctl_f() at devfs_ioctl_f+0x6d > kern_ioctl() at kern_ioctl+0xa3 > ioctl() at ioctl+0xf9 > syscall() at syscall+0x1ce > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8007187ec, rsp = > 0x7fffffffecd8, rbp = 0x7fffffffee50 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff801d9cf4 > stack pointer = 0x10:0xffffffff9ed4aa00 > frame pointer = 0x10:0xffffffff9ed4aa30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 748 (acpiconf) Try the attached patch. It will reject suspend requests while still allowing power-off. This will have to be this way until amd64 suspend/resume is implemented. -Nate --------------050606020709050303060101 Content-Type: text/x-patch; name="acpi-wake.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi-wake.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.241 diff -u -r1.241 acpi.c --- sys/dev/acpica/acpi.c 30 Jun 2007 17:27:31 -0000 1.241 +++ sys/dev/acpica/acpi.c 9 Sep 2007 21:13:04 -0000 @@ -2173,6 +2173,11 @@ return (ENXIO); } +#if !defined(__i386__) + /* This platform does not support acpi suspend/resume. */ + return (EOPNOTSUPP); +#endif + /* If a suspend request is already in progress, just return. */ ACPI_LOCK(acpi); if (sc->acpi_next_sstate != 0) { --------------050606020709050303060101-- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 08:20:08 2007 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AFAD16A41A for ; Mon, 10 Sep 2007 08:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3E3E13C45A for ; Mon, 10 Sep 2007 08:20:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8A8K72d005320 for ; Mon, 10 Sep 2007 08:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8A8K7Ab005319; Mon, 10 Sep 2007 08:20:07 GMT (envelope-from gnats) Date: Mon, 10 Sep 2007 08:20:07 GMT Message-Id: <200709100820.l8A8K7Ab005319@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Martin Tournoij Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Tournoij List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 08:20:08 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Martin Tournoij To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Mon, 10 Sep 2007 09:58:28 +0200 Getting the same error on my AMD Athlon XP. ACPI in general does seem to work fine, I can put my pc into sleep mode, get proper sysctl values, ect. dmesg: http://www.rwxrwxrwx.net/dmesg.phong.txt acpidump -dt: http://www.rwxrwxrwx.net/acpidump.phong.txt Regards, Martin Tournoij From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 11:07:53 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC8AF16A418 for ; Mon, 10 Sep 2007 11:07:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 73D2A13C46B for ; Mon, 10 Sep 2007 11:07:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8AB7r4Y017147 for ; Mon, 10 Sep 2007 11:07:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8AB7qWp017143 for freebsd-acpi@FreeBSD.org; Mon, 10 Sep 2007 11:07:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Sep 2007 11:07:52 GMT Message-Id: <200709101107.l8AB7qWp017143@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 11:07:53 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 s i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/114113 acpi [patch] ACPI kernel panic during S3 suspend / resume o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116169 acpi [PATCH] acpi_ibm => psm0 not found problem 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th o kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi Dell C810 - ACPI problem o kern/114722 acpi [acpi] [patch] Nearly duplicate p-state entries report 18 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 13:07:19 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B34A16A420; Mon, 10 Sep 2007 13:07:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id B957A13C480; Mon, 10 Sep 2007 13:07:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IUiyq-000IAz-3f; Mon, 10 Sep 2007 16:07:17 +0300 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l8AD74SX042427; Mon, 10 Sep 2007 16:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l8AD7434042426; Mon, 10 Sep 2007 16:07:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Sep 2007 16:07:04 +0300 From: Kostik Belousov To: Nate Lawson Message-ID: <20070910130704.GC53667@deviant.kiev.zoral.com.ua> References: <46E0777A.8070901@root.org> <20070907133901.GL53667@deviant.kiev.zoral.com.ua> <46E45A6D.1010805@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TIEGfCGDzZzDroj5" Content-Disposition: inline In-Reply-To: <46E45A6D.1010805@root.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 7155bbd8d023de41950ebecbe4708355 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1451 [September 10 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 13:07:19 -0000 --TIEGfCGDzZzDroj5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 09, 2007 at 01:41:17PM -0700, Nate Lawson wrote: > Kostik Belousov wrote: > > On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > >> I've done some major rework on the EC driver. This should help with > >> various problems, including timeouts while checking battery status or > >> temperature. The attached patches are for 6.x and 7.x. Please test a= nd > >> let me know if you get any new errors on dmesg or if it fixes things f= or > >> you (especially HP/Compaq laptop owners). > > Ok, I tryed it on Acer 2490-kind of laptop. I see no difference with the > > patch, battery status seems to be reported correctly both before and af= ter > > applying it. > >=20 > > The only thing I want to note is that reboot on the laptop is turned in= to > > poweroff. You said in the followup to original letter that poweroff is > > turned into reboot, I did not checked it; this is opposite. >=20 > Please test this revised version. All it changes is forcing polling > mode back on during reboot/shutdown. I tested with ecng-7b. Both reboot and halt -p worked as expected. Thanks. --TIEGfCGDzZzDroj5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG5UF3C3+MBN1Mb4gRAvtSAJ9conuDACy+xhtiUfxYLtWHWbFWUQCdHm6A uhs/oTu5AVV0dN5sJlNNAz0= =l7tf -----END PGP SIGNATURE----- --TIEGfCGDzZzDroj5-- From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 13:43:11 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA6A16A419 for ; Mon, 10 Sep 2007 13:43:11 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id A5BFF13C459 for ; Mon, 10 Sep 2007 13:43:11 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so989983rvb for ; Mon, 10 Sep 2007 06:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=t4Y+kLc7RejpKF63Qo5AIwW3RWv7u5oFtCH+Ye+QR6c=; b=Frh6FjebzARrg99fGGFbjollPm4TDjQM+mnq56+feIzeQdWMTJoLl2Ki8QDeGJn4+FvtioS0nuSaudOTXWrliPGMEGFvUTwwEBgsQw8skUF7ISDmLM7HKW8FZVGCpFeZswlVaCFlgTSLzhsvkuVvQrFkUXRw0fVI5WhpvIQMNiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ePxUGjDg9v9d7S+0YvaRs6+/Lntv4gP3sKN5GPseomdAiTFo4FMoWg2nB2e3POysBeypYUW1Pmws4YRnb1WOa1jcfWFFKisnsxI5GuJTQP1nHvR4AMAaxydzXiEQLFilBHaQd9ManxfncrHOzJlqW/vIx8jLJLEF6hr/pOj8Slw= Received: by 10.141.167.5 with SMTP id u5mr972812rvo.1189431791128; Mon, 10 Sep 2007 06:43:11 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Mon, 10 Sep 2007 06:43:11 -0700 (PDT) Message-ID: <632825b40709100643t40c41376xc69e7096d637fa8c@mail.gmail.com> Date: Mon, 10 Sep 2007 10:43:11 -0300 From: "William Grzybowski" To: "Kevin Oberman" In-Reply-To: <20070907213724.F1D384500E@ptavv.es.net> MIME-Version: 1.0 References: <20070907213724.F1D384500E@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: powerd algorithms X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 13:43:12 -0000 On 9/7/07, Kevin Oberman wrote: > > > Date: Fri, 7 Sep 2007 22:14:53 +0200 > > From: "Cyrille Szymanski" > > Sender: owner-freebsd-acpi@freebsd.org > > > > > Hi Cyrille, > > > > > > Would be nice if you can share you research about powerd with me, i am > really interested in this subject... > > > > My biggest concerns (and why I more or less lost interest in this > > project) are that : > > 1. I believe FLAT to be very close to, if not the best universal > > algorithm possible; > > 2. I was unable to find a decent way to quantify the power savings of > > each approach other than by simulation or using current probes. > > > > Power consumption depends both on frequency and workload and since I > > have no idea how CPUs behave in practice I cannot design any smarter > > solution. The best solution is likely to be something specific to each > > CPU model/brand (see bullet 1). This would require building a database > > of the optimum settings for each CPU model. I am not sure we find > > enough people willing to experiment, unless... (see bullet 2). > > > > Note: I am not convinced that my laptop uses less power when running > > at its lowest frequency when I see the heat that it emits in that > > mode. > > > > > Actually the powerd has 3 modes right? [min,max,adaptive] > > > The adaptive uses the relation about idle and total usage, but just > one by one, i was thinking in use a short historical of this cpu usage > related by idle and create some profiles over it (like ondemand and > conservative in linux)... > > > > AFAIK the 'adaptive' mode increases by two steps and decreases by one > > step (this would be more responsive). If you look at CVS revisions for > > powerd.c you'll see what has been tried over the years (rev 1.9 for > > example) > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/powerd/powerd.c > > > > Have you checked the research papers describing approaches such as > > PAST, FLAT etc. ? I did not investigate the linux 'ondemand' and I have to take a look in ondemand code, but i always worked fine to me, maybe it really worth a try as you said. > 'conservative' modes but maybe they are worth a try. As I understand > > it, FreeBSD lacks only the 'ondemand' mode ? Not completely, but I will take a look. Cyrille, > > Three ago I did some analysis of the effects of power management on some > laptops of that era. Most had either no voltage-frequency management or > only the basic SST...not EST. I really should do some current testing. I > still think I have all of the scripts I used to do this, but all testing > was done at 100% CPU utilization or idle. > > I found that simple CPU throttling was not too effective as a power > management tool. Not totally ineffective, but not very good. SpeedStep > was effective. I suspect EST with both voltage and frequency control > would be much better as would the AMD and maybe VIA equivalents. > > I was planning on modifying my tests to report at various levels of CPU > utilization, but then got tied up on other things and have not gotten > back to it. I did determine that running at 800 MHz frequency (SST) with > the CPU loaded at 90% used quite a bit more power than running at 1.2 > GHZ at 60%. I would be happy to provide my perl scripts to someone who > would like to expand them to test at other than 100% and 0% load. > Hi Kevin, You can send this scripts to me, thanks. As I can understand you are saying throttling is not that effective about power consuming, but I guess this is not the unique point to discuss. Tell me if i got i wrong ;) Better than this is just use low frequencies when you don't need higher process power and with it, take down the >cpu temperature< and less use of the cooler... Bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 14:48:33 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94ABF16A421 for ; Mon, 10 Sep 2007 14:48:33 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 08D5E13C465 for ; Mon, 10 Sep 2007 14:48:32 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so819568nfd for ; Mon, 10 Sep 2007 07:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VxcxPWefnCokp3hJ7P7aoed8ngSIWH+PPzooQRzwQSU=; b=QdmNuqDr1qzkdkB569jeysa5G5LKmil+lxS8c3Ubuqyr0DwuvB6KUZ5dAI+fqMvUytkZOYFysDsllSAC0ddKG3oRoOg/P/5TBplpLDxY8pcO+lu4PDy6DyfxWnlJ4bDN5jT3NZzNy0fgWZJbhTVWIY4c7lVEMpDK9kVyhbBLuu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DIbCWxi8HppXuhBJ74izV15pCvQSCBjYr0cThQz+7QWTx4adB096lL/TjV0GQOeC7hJOiHWPWpLM7+hKedY0YP6D8Km04cHp6JK0gqkmfZq2sWH1xjyJz/x3JM8bJxgPcBur1ZSvYPM4ZPkjt7tfRBvACR+G5NjmwkvxSPgcrbE= Received: by 10.86.58.3 with SMTP id g3mr3775898fga.1189435711713; Mon, 10 Sep 2007 07:48:31 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Mon, 10 Sep 2007 07:48:31 -0700 (PDT) Message-ID: <325305250709100748l541ed79u1df6f0e018b921f2@mail.gmail.com> Date: Mon, 10 Sep 2007 18:48:31 +0400 From: Denis To: "Nate Lawson" In-Reply-To: <46E45CFE.2010206@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E0784D.6030600@root.org> <325305250709082102m45a5dbfpced3291a2a86f372@mail.gmail.com> <46E45CFE.2010206@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 14:48:33 -0000 I tried to search for this patch - but unfortunately didn't find anything. Is it exist somewhere in the Internet? If so, could you please point on it? Many-many thanks in advance. Best regards, Denis. On 9/10/07, Nate Lawson wrote: > Denis wrote: > > Sorry for the delay in answer. > > > > Nope, this patch didn't help me. If I boot with ACPI enabled (compaq > > nc6220 laptop) I get the same error: > > > > --- > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > Mutex [0] [20070320] > > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > Mutex [0] [20070320] > > ACPI Error (exutils-0180): Could not acquire AML Interpreter mutex [20070320] > > ACPI Error (psparse-0626): Method parse/execution failed [\_TZ_.C265] > > (Node 0xc2e3fbe0), AE_TIME > > ACPI Error (psparse-0626): Method parse/execution failed > > [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME > > acpi_tz0: error fetching current temperature -- AE_TIME > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot release [20070320] > > ACPI Error (exutils-0250): Could not acquire AML Interpreter mutex [20070320] > > --- > > > > and have switch power off to reboot. > > > > Best regards, Denis. > > Ok, thanks, this is a different problem. Jung-uk Kim has a patch that > may help mutex behavior. > > -- > Nate > From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 10 15:16:01 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5115016A417 for ; Mon, 10 Sep 2007 15:16:01 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8D613C467 for ; Mon, 10 Sep 2007 15:15:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8AF1Adq048104; Mon, 10 Sep 2007 11:01:10 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Mon, 10 Sep 2007 11:00:59 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E45CFE.2010206@root.org> <325305250709100748l541ed79u1df6f0e018b921f2@mail.gmail.com> In-Reply-To: <325305250709100748l541ed79u1df6f0e018b921f2@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709101101.03340.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4228/Mon Sep 10 09:38:29 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 15:16:01 -0000 On Monday 10 September 2007 10:48 am, Denis wrote: > I tried to search for this patch - but unfortunately didn't find > anything. > > Is it exist somewhere in the Internet? If so, could you please > point on it? > > Many-many thanks in advance. I just sent it to you privately but you can find it here: http://people.freebsd.org/~jkim/acpica/OsdSynch.diff Jung-uk Kim > Best regards, Denis. > > On 9/10/07, Nate Lawson wrote: > > Denis wrote: > > > Sorry for the delay in answer. > > > > > > Nope, this patch didn't help me. If I boot with ACPI enabled > > > (compaq nc6220 laptop) I get the same error: > > > > > > --- > > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not > > > acquire Mutex [0] [20070320] > > > ACPI Error (exutils-0180): Could not acquire AML Interpreter > > > mutex [20070320] ACPI Error (utmutex-0421): Mutex[0] is not > > > acquired, cannot release [20070320] ACPI Error (exutils-0250): > > > Could not acquire AML Interpreter mutex [20070320] ACPI > > > Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > > Mutex [0] [20070320] > > > ACPI Error (exutils-0180): Could not acquire AML Interpreter > > > mutex [20070320] ACPI Error (psparse-0626): Method > > > parse/execution failed [\_TZ_.C265] (Node 0xc2e3fbe0), AE_TIME > > > ACPI Error (psparse-0626): Method parse/execution failed > > > [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME > > > acpi_tz0: error fetching current temperature -- AE_TIME > > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot > > > release [20070320] ACPI Error (exutils-0250): Could not acquire > > > AML Interpreter mutex [20070320] --- > > > > > > and have switch power off to reboot. > > > > > > Best regards, Denis. > > > > Ok, thanks, this is a different problem. Jung-uk Kim has a patch > > that may help mutex behavior. > > > > -- > > Nate > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to > "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 05:25:02 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0289416A41B for ; Tue, 11 Sep 2007 05:25:02 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5123D13C48A for ; Tue, 11 Sep 2007 05:25:01 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1808625mue for ; Mon, 10 Sep 2007 22:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=P7XK/RQ04hsbunexULYSdT/hfJGRzQour5Y1qQDgVDs=; b=C1ECfZuWjH/gb5OltxdS6q3VEk/ISSOeh4m+GVuUjgfLH8HLFb6bMb9N0sJmSXnSaGvTCv94mKLYuIlJuWcuYffMSWmyssgWOMVbo3zx4xisJoGlxQH7pgC3PPd39DU23r68eWibz55esvyEmmUt5xCaNwtOerxRjkF27nlNnh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M6I7V6hz/N1yZFv/MaAje+Hh0b6Daf8hiv6KezbMYK9rWBxxEF0ZRhmb6X9TwEGpzn07G0Df4HVS1Qpg2G+Y8+Bt+cJVlBa8xaBwvHhJgfPrSELMA0o1fMmsIP3yN3cf1AiWmMQMI1MNMAPEg64nCmDPN80b6XdZEXDbyQajLhM= Received: by 10.86.58.3 with SMTP id g3mr4314357fga.1189488299746; Mon, 10 Sep 2007 22:24:59 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Mon, 10 Sep 2007 22:24:59 -0700 (PDT) Message-ID: <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> Date: Tue, 11 Sep 2007 09:24:59 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709101101.03340.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E45CFE.2010206@root.org> <325305250709100748l541ed79u1df6f0e018b921f2@mail.gmail.com> <200709101101.03340.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 05:25:02 -0000 Unfortunately it doesn't help. I tried it with src from September 10, without patch from Nate. When I tried it without acfreebsd.h patch, kernel didn't compile. When I tried it with acfreebsd.h patch kernel compiled, but I couldn't boot with ACPI - got kernel panic... Best regards, Denis On 9/10/07, Jung-uk Kim wrote: > On Monday 10 September 2007 10:48 am, Denis wrote: > > I tried to search for this patch - but unfortunately didn't find > > anything. > > > > Is it exist somewhere in the Internet? If so, could you please > > point on it? > > > > Many-many thanks in advance. > > I just sent it to you privately but you can find it here: > > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff > > Jung-uk Kim > > > Best regards, Denis. > > > > On 9/10/07, Nate Lawson wrote: > > > Denis wrote: > > > > Sorry for the delay in answer. > > > > > > > > Nope, this patch didn't help me. If I boot with ACPI enabled > > > > (compaq nc6220 laptop) I get the same error: > > > > > > > > --- > > > > ACPI Exception (utmutex-0376): AE_TIME, Thread 27 could not > > > > acquire Mutex [0] [20070320] > > > > ACPI Error (exutils-0180): Could not acquire AML Interpreter > > > > mutex [20070320] ACPI Error (utmutex-0421): Mutex[0] is not > > > > acquired, cannot release [20070320] ACPI Error (exutils-0250): > > > > Could not acquire AML Interpreter mutex [20070320] ACPI > > > > Exception (utmutex-0376): AE_TIME, Thread 27 could not acquire > > > > Mutex [0] [20070320] > > > > ACPI Error (exutils-0180): Could not acquire AML Interpreter > > > > mutex [20070320] ACPI Error (psparse-0626): Method > > > > parse/execution failed [\_TZ_.C265] (Node 0xc2e3fbe0), AE_TIME > > > > ACPI Error (psparse-0626): Method parse/execution failed > > > > [\_TZ_.TZ1_._TMP] (Node 0xc2e43920), AE_TIME > > > > acpi_tz0: error fetching current temperature -- AE_TIME > > > > ACPI Error (utmutex-0421): Mutex[0] is not acquired, cannot > > > > release [20070320] ACPI Error (exutils-0250): Could not acquire > > > > AML Interpreter mutex [20070320] --- > > > > > > > > and have switch power off to reboot. > > > > > > > > Best regards, Denis. > > > > > > Ok, thanks, this is a different problem. Jung-uk Kim has a patch > > > that may help mutex behavior. > > > > > > -- > > > Nate > > > > _______________________________________________ > > freebsd-acpi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > > To unsubscribe, send any mail to > > "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 16:01:43 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1464116A420 for ; Tue, 11 Sep 2007 16:01:43 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id C706E13C461 for ; Tue, 11 Sep 2007 16:01:42 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8BG1fZ6033515; Tue, 11 Sep 2007 12:01:41 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Tue, 11 Sep 2007 12:01:35 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709101101.03340.jkim@FreeBSD.org> <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> In-Reply-To: <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709111201.39306.jkim@FreeBSD.org> Cc: Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 16:01:43 -0000 On Tuesday 11 September 2007 01:24 am, Denis wrote: > Unfortunately it doesn't help. > > I tried it with src from September 10, without patch from Nate. Can you try it with his patch as well? > When I tried it without acfreebsd.h patch, kernel didn't compile. That is strange because I can compile kernel with or without it. In fact, I have been using it without the acfreebsd.h patch for months. :-( > When I tried it with acfreebsd.h patch kernel compiled, but I > couldn't boot with ACPI - got kernel panic... Can you describe the panic messages? Thanks, Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 18:32:35 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF3C16A41A for ; Tue, 11 Sep 2007 18:32:35 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9D713C48D for ; Tue, 11 Sep 2007 18:32:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 79271 invoked from network); 11 Sep 2007 18:32:33 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 11 Sep 2007 18:32:33 -0000 Message-ID: <46E6DF34.1060304@root.org> Date: Tue, 11 Sep 2007 11:32:20 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: William Grzybowski References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> In-Reply-To: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------010202030307050802010105" Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 18:32:35 -0000 This is a multi-part message in MIME format. --------------010202030307050802010105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit William Grzybowski wrote: > On 9/6/07, *Nate Lawson* > wrote: > > Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please > test and > > let me know if you get any new errors on dmesg or if it fixes > things for > > you (especially HP/Compaq laptop owners). > > > > If you still have problems, try setting each of these tunables > > individually and then both together (i.e., in > /boot/loader.conf). Note > > that this will be four (4) test runs total, so don't just set both and > > say it doesn't work. > > > > debug.acpi.ec.burst= "1" > > debug.acpi.ec.polled="1" > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > > problems in either regular or burst mode. > > > > > > Commit message: > > Rewrite the EC driver event model. The main goal is to avoid > > polling/interrupt-driven fallback and instead use polling only during > > boot and pure interrupt-driven mode after boot. Polled mode could be > > relegated completely to a legacy role if we could enable interrupts > > during boot. Polled mode can be forced after boot by setting > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > One minor note -- power off shutdown (shutdown/halt -p) is turned into a > (safe) reboot with this patch. I have tested the fix, which is just to > force polled mode during shutdown as well. I don't have time to > re-roll > the patch today but will send tomorrow. > > Please test the patch as posted, ignoring that minor issue. The test > results during normal use are still valid. > > > Hi Nate, > > I tested this patch on my acer notebook (intel chipset) and i did not > notice any changes, unless some errors on dmesg, like: > acpi_ec0: EcCommand: no response to 0x84 > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcCommand: no response to 0x82 > acpi_ec0: EcCommand: no response to 0x80 > ACPI Error (psparse-0626): Method parse/execution failed > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE As I noted before, your system enters the poll loop with the status appearing to be already complete. Can you get back to me on my previous questions, especially whether forcing polled mode works for you? I didn't see any errors in that dmesg case. I've updated the patches to do one final check if the interrupt-driven mode gets a timeout. If the status is complete, it will force the system back into polled mode since interrupt mode doesn't work. It also has a case for polled mode during boot where the status appears to be already complete. It waits a short while before actually checking the status, just in case the EC is really slow and hasn't gotten to work on the new request yet. Give it a try also, with no tunables set. -Nate --------------010202030307050802010105 Content-Type: text/x-patch; name="ecng-6c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6c.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.65.2.3 diff -u -r1.65.2.3 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 4 Sep 2007 22:40:39 -0000 1.65.2.3 +++ sys/dev/acpica/acpi_ec.c 11 Sep 2007 18:12:09 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -142,9 +33,9 @@ #include #include #include +#include #include #include -#include #include #include @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -188,15 +79,15 @@ * | | | +--------- Burst Mode Enabled? * | | +----------- SCI Event? * | +------------- SMI Event? - * +--------------- + * +--------------- * */ typedef UINT8 EC_STATUS; #define EC_FLAG_OUTPUT_BUFFER ((EC_STATUS) 0x01) #define EC_FLAG_INPUT_BUFFER ((EC_STATUS) 0x02) +#define EC_FLAG_DATA_IS_CMD ((EC_STATUS) 0x08) #define EC_FLAG_BURST_MODE ((EC_STATUS) 0x10) -#define EC_FLAG_SCI ((EC_STATUS) 0x20) /* * EC_EVENT: @@ -208,6 +99,10 @@ #define EC_EVENT_OUTPUT_BUFFER_FULL ((EC_EVENT) 0x01) #define EC_EVENT_INPUT_BUFFER_EMPTY ((EC_EVENT) 0x02) #define EC_EVENT_SCI ((EC_EVENT) 0x20) +#define EC_EVENT_SMI ((EC_EVENT) 0x40) + +/* Data byte returned after burst enable indicating it was successful. */ +#define EC_BURST_ACK 0x90 /* * Register access primitives @@ -227,11 +122,11 @@ /* Embedded Controller Boot Resources Table (ECDT) */ typedef struct { ACPI_TABLE_HEADER header; - ACPI_GENERIC_ADDRESS control; - ACPI_GENERIC_ADDRESS data; - UINT32 uid; - UINT8 gpe_bit; - char ec_id[0]; + ACPI_GENERIC_ADDRESS Control; + ACPI_GENERIC_ADDRESS Data; + UINT32 Uid; + UINT8 Gpe; + char Id[0]; } ACPI_TABLE_ECDT; /* Additional params to pass from the probe routine */ @@ -243,7 +138,7 @@ }; /* Indicate that this device has already been probed via ECDT. */ -#define DEV_ECDT(x) (acpi_get_magic(x) == (int)&acpi_ec_devclass) +#define DEV_ECDT(x) (acpi_get_magic(x) == (uintptr_t)&acpi_ec_devclass) /* * Driver softc. @@ -254,8 +149,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -268,6 +162,9 @@ int ec_glk; int ec_glkhandle; + int ec_burstactive; + int ec_sci_pend; + u_int ec_gencount; }; /* @@ -277,11 +174,11 @@ */ #define EC_LOCK_TIMEOUT 1000 -/* Default interval in microseconds for the status polling loop. */ -#define EC_POLL_DELAY 10 +/* Default delay in microseconds between each run of the status polling loop. */ +#define EC_POLL_DELAY 5 -/* Total time in ms spent in the poll loop waiting for a response. */ -#define EC_POLL_TIMEOUT 100 +/* Total time in ms spent waiting for a response from EC. */ +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -289,46 +186,57 @@ ((event) == EC_EVENT_INPUT_BUFFER_EMPTY && \ ((status) & EC_FLAG_INPUT_BUFFER) == 0)) -static int ec_poll_timeout = EC_POLL_TIMEOUT; -TUNABLE_INT("hw.acpi.ec.poll_timeout", &ec_poll_timeout); - ACPI_SERIAL_DECL(ec, "ACPI embedded controller"); -static __inline ACPI_STATUS +SYSCTL_DECL(_debug_acpi); +SYSCTL_NODE(_debug_acpi, OID_AUTO, ec, CTLFLAG_RD, NULL, "EC debugging"); + +static int ec_burst_mode; +TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, + "Enable use of burst mode (faster for nearly all systems)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); +static int ec_timeout = EC_TIMEOUT; +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 ACPI_STATUS EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; - /* Always acquire the exclusive lock. */ + /* If _GLK is non-zero, acquire the global lock. */ status = AE_OK; - ACPI_SERIAL_BEGIN(ec); - - /* If _GLK is non-zero, also acquire the global lock. */ if (sc->ec_glk) { status = AcpiAcquireGlobalLock(EC_LOCK_TIMEOUT, &sc->ec_glkhandle); if (ACPI_FAILURE(status)) - ACPI_SERIAL_END(ec); + return (status); } - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); - ACPI_SERIAL_END(ec); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -366,10 +274,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -387,20 +297,20 @@ status = AcpiGetFirmwareTable("ECDT", 1, ACPI_LOGICAL_ADDRESSING, &hdr); ecdt = (ACPI_TABLE_ECDT *)hdr; if (ACPI_FAILURE(status) || - ecdt->control.RegisterBitWidth != 8 || - ecdt->data.RegisterBitWidth != 8) { + ecdt->Control.RegisterBitWidth != 8 || + ecdt->Data.RegisterBitWidth != 8) { return; } /* Create the child device with the given unit number. */ - child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->uid); + child = BUS_ADD_CHILD(parent, 0, "acpi_ec", ecdt->Uid); if (child == NULL) { printf("%s: can't add child\n", __func__); return; } /* Find and save the ACPI handle for this device. */ - status = AcpiGetHandle(NULL, ecdt->ec_id, &h); + status = AcpiGetHandle(NULL, ecdt->Id, &h); if (ACPI_FAILURE(status)) { device_delete_child(parent, child); printf("%s: can't get handle\n", __func__); @@ -409,9 +319,9 @@ acpi_set_handle(child, h); /* Set the data and CSR register addresses. */ - bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->data.Address, + bus_set_resource(child, SYS_RES_IOPORT, 0, ecdt->Data.Address, /*count*/1); - bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->control.Address, + bus_set_resource(child, SYS_RES_IOPORT, 1, ecdt->Control.Address, /*count*/1); /* @@ -423,11 +333,11 @@ */ params = malloc(sizeof(struct acpi_ec_params), M_TEMP, M_WAITOK | M_ZERO); params->gpe_handle = NULL; - params->gpe_bit = ecdt->gpe_bit; - params->uid = ecdt->uid; + params->gpe_bit = ecdt->Gpe; + params->uid = ecdt->Uid; acpi_GetInteger(h, "_GLK", ¶ms->glk); acpi_set_private(child, params); - acpi_set_magic(child, (int)&acpi_ec_devclass); + acpi_set_magic(child, (uintptr_t)&acpi_ec_devclass); /* Finish the attach process. */ if (device_probe_and_attach(child) != 0) @@ -601,7 +511,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -636,7 +546,7 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, @@ -688,100 +598,92 @@ struct acpi_ec_softc *sc = (struct acpi_ec_softc *)Context; UINT8 Data; ACPI_STATUS Status; - EC_STATUS EcStatus; char qxx[5]; ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); + /* Serialize user access with EcSpaceHandler(). */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - */ - EcStatus = EC_GET_CSR(sc); - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was not SCI, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - EcUnlock(sc); - goto re_enable; - } - - /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - sprintf(qxx, "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_NOT_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) { struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; + EC_STATUS EcStatus; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (which could - * potentially sleep.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); - /* Schedule the GPE query handler. */ - Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, - Context); - if (ACPI_FAILURE(Status)) { - printf("Queuing GPE query handler failed.\n"); - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableEvent failed\n"); + /* + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. + */ + EcStatus = EC_GET_CSR(sc); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); + Status = AcpiOsQueueForExecution(OSD_PRIORITY_GPE, EcGpeQueryHandler, + Context); + if (ACPI_SUCCESS(Status)) + sc->ec_sci_pend = TRUE; + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - return (0); } @@ -825,6 +727,18 @@ EcAddr = Address; Status = AE_ERROR; + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -850,193 +764,264 @@ if (ACPI_FAILURE(Status)) break; } - EcUnlock(sc); + return_ACPI_STATUS (Status); } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, period, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - /* - * Wait for 1 us before checking the CSR. Testing shows about - * 50% of requests complete in 1 us and 90% of them complete - * in 5 us or less. - */ - AcpiOsStall(1); - /* - * Poll the EC status register for up to 1 ms in chunks of 10 us - * to detect completion of the last command. + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. */ - for (i = 0; i < 1000 / EC_POLL_DELAY; i++) { - EcStatus = EC_GET_CSR(sc); - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; - break; + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - period = i * EC_POLL_DELAY; - /* - * If we still don't have a response and we're up and running, wait up - * to ec_poll_timeout ms for completion, sleeping for chunks of 10 ms. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - count = ec_poll_timeout / 10; - if (count == 0) + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) count = 1; - slp_ival = hz / 100; - if (slp_ival == 0) - slp_ival = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (EVENT_READY(Event, EcStatus)) { - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; - } - if (!cold) - retval = tsleep(&sc->ec_csrvalue, PZERO, "ecpoll", slp_ival); - else - AcpiOsStall(10000); + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); } - } - /* Calculate new delay and log it. */ - if (slp_ival > 0) - period += i * 10000; - CTR2(KTR_ACPI, "ec got event %#x after %d us", EcStatus, period); + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; + } + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); + } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) { - ACPI_STATUS Status; - EC_EVENT Event; + ACPI_STATUS status; + EC_EVENT event; + EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); + /* Don't use burst mode if user disabled it. */ + if (!ec_burst_mode && cmd == EC_COMMAND_BURST_ENABLE) + return (AE_ERROR); + /* Decide what to wait for based on command type. */ switch (cmd) { case EC_COMMAND_READ: case EC_COMMAND_WRITE: case EC_COMMAND_BURST_DISABLE: - Event = EC_EVENT_INPUT_BUFFER_EMPTY; + event = EC_EVENT_INPUT_BUFFER_EMPTY; break; case EC_COMMAND_QUERY: case EC_COMMAND_BURST_ENABLE: - Event = EC_EVENT_OUTPUT_BUFFER_FULL; + event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ + CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - Status = EcWaitEvent(sc, Event); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - - return (Status); + status = EcWaitEvent(sc, event, gen_count); + if (ACPI_SUCCESS(status)) { + /* If we succeeded, burst flag should now be present. */ + if (cmd == EC_COMMAND_BURST_ENABLE) { + ec_status = EC_GET_CSR(sc); + if ((ec_status & EC_FLAG_BURST_MODE) == 0) + status = AE_ERROR; + } + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); + return (status); } static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_READ); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_READ); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); + return (status); } - *Data = EC_GET_DATA(sc); -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { - ACPI_STATUS Status; + ACPI_STATUS status; + UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); -#ifdef notyet /* If we can't start burst mode, continue anyway. */ - EcCommand(sc, EC_COMMAND_BURST_ENABLE); -#endif + status = EcCommand(sc, EC_COMMAND_BURST_ENABLE); + if (status == AE_OK) { + data = EC_GET_DATA(sc); + if (data == EC_BURST_ACK) { + CTR0(KTR_ACPI, "ec burst enabled"); + sc->ec_burstactive = TRUE; + } + } - Status = EcCommand(sc, EC_COMMAND_WRITE); - if (ACPI_FAILURE(Status)) - return (Status); + status = EcCommand(sc, EC_COMMAND_WRITE); + if (ACPI_FAILURE(status)) + return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); + return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - Status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); - return (Status); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); + if (ACPI_FAILURE(status)) { + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); + return (status); } -#ifdef notyet if (sc->ec_burstactive) { - Status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); - if (ACPI_FAILURE(Status)) - return (Status); + sc->ec_burstactive = FALSE; + status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); + if (ACPI_FAILURE(status)) + return (status); + CTR0(KTR_ACPI, "ec disabled burst ok"); } -#endif return (AE_OK); } --------------010202030307050802010105 Content-Type: text/x-patch; name="ecng-7c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7c.diff" Index: sys/dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.75 diff -u -r1.75 acpi_ec.c --- sys/dev/acpica/acpi_ec.c 15 Jun 2007 18:02:33 -0000 1.75 +++ sys/dev/acpica/acpi_ec.c 11 Sep 2007 18:31:32 -0000 @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003-2007 Nate Lawson * Copyright (c) 2000 Michael Smith * Copyright (c) 2000 BSDi * All rights reserved. @@ -25,115 +25,6 @@ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ -/*- - ****************************************************************************** - * - * 1. Copyright Notice - * - * Some or all of this work - Copyright (c) 1999, Intel Corp. All rights - * reserved. - * - * 2. License - * - * 2.1. This is your license from Intel Corp. under its intellectual property - * rights. You may have additional license terms from the party that provided - * you this software, covering your right to use that party's intellectual - * property rights. - * - * 2.2. Intel grants, free of charge, to any person ("Licensee") obtaining a - * copy of the source code appearing in this file ("Covered Code") an - * irrevocable, perpetual, worldwide license under Intel's copyrights in the - * base code distributed originally by Intel ("Original Intel Code") to copy, - * make derivatives, distribute, use and display any portion of the Covered - * Code in any form, with the right to sublicense such rights; and - * - * 2.3. Intel grants Licensee a non-exclusive and non-transferable patent - * license (with the right to sublicense), under only those claims of Intel - * patents that are infringed by the Original Intel Code, to make, use, sell, - * offer to sell, and import the Covered Code and derivative works thereof - * solely to the minimum extent necessary to exercise the above copyright - * license, and in no event shall the patent license extend to any additions - * to or modifications of the Original Intel Code. No other license or right - * is granted directly or by implication, estoppel or otherwise; - * - * The above copyright and patent license is granted only if the following - * conditions are met: - * - * 3. Conditions - * - * 3.1. Redistribution of Source with Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification with rights to further distribute source must include - * the above Copyright Notice, the above License, this list of Conditions, - * and the following Disclaimer and Export Compliance provision. In addition, - * Licensee must cause all Covered Code to which Licensee contributes to - * contain a file documenting the changes Licensee made to create that Covered - * Code and the date of any change. Licensee must include in that file the - * documentation of any changes made by any predecessor Licensee. Licensee - * must include a prominent statement that the modification is derived, - * directly or indirectly, from Original Intel Code. - * - * 3.2. Redistribution of Source with no Rights to Further Distribute Source. - * Redistribution of source code of any substantial portion of the Covered - * Code or modification without rights to further distribute source must - * include the following Disclaimer and Export Compliance provision in the - * documentation and/or other materials provided with distribution. In - * addition, Licensee may not authorize further sublicense of source of any - * portion of the Covered Code, and must include terms to the effect that the - * license from Licensee to its licensee is limited to the intellectual - * property embodied in the software Licensee provides to its licensee, and - * not to intellectual property embodied in modifications its licensee may - * make. - * - * 3.3. Redistribution of Executable. Redistribution in executable form of any - * substantial portion of the Covered Code or modification must reproduce the - * above Copyright Notice, and the following Disclaimer and Export Compliance - * provision in the documentation and/or other materials provided with the - * distribution. - * - * 3.4. Intel retains all right, title, and interest in and to the Original - * Intel Code. - * - * 3.5. Neither the name Intel nor any other trademark owned or controlled by - * Intel shall be used in advertising or otherwise to promote the sale, use or - * other dealings in products derived from or relating to the Covered Code - * without prior written authorization from Intel. - * - * 4. Disclaimer and Export Compliance - * - * 4.1. INTEL MAKES NO WARRANTY OF ANY KIND REGARDING ANY SOFTWARE PROVIDED - * HERE. ANY SOFTWARE ORIGINATING FROM INTEL OR DERIVED FROM INTEL SOFTWARE - * IS PROVIDED "AS IS," AND INTEL WILL NOT PROVIDE ANY SUPPORT, ASSISTANCE, - * INSTALLATION, TRAINING OR OTHER SERVICES. INTEL WILL NOT PROVIDE ANY - * UPDATES, ENHANCEMENTS OR EXTENSIONS. INTEL SPECIFICALLY DISCLAIMS ANY - * IMPLIED WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT AND FITNESS FOR A - * PARTICULAR PURPOSE. - * - * 4.2. IN NO EVENT SHALL INTEL HAVE ANY LIABILITY TO LICENSEE, ITS LICENSEES - * OR ANY OTHER THIRD PARTY, FOR ANY LOST PROFITS, LOST DATA, LOSS OF USE OR - * COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, - * SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, UNDER ANY - * CAUSE OF ACTION OR THEORY OF LIABILITY, AND IRRESPECTIVE OF WHETHER INTEL - * HAS ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. THESE LIMITATIONS - * SHALL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY - * LIMITED REMEDY. - * - * 4.3. Licensee shall not export, either directly or indirectly, any of this - * software or system incorporating such software without first obtaining any - * required license or other approval from the U. S. Department of Commerce or - * any other agency or department of the United States Government. In the - * event Licensee exports any such software from the United States or - * re-exports any such software from a foreign destination, Licensee shall - * ensure that the distribution and export/re-export of the software is in - * compliance with all laws, regulations, orders, or other restrictions of the - * U.S. Export Administration Regulations. Licensee agrees that neither it nor - * any of its subsidiaries will export/re-export any technical data, process, - * software, or service, directly or indirectly, to any country for which the - * United States government or any agency thereof requires an export license, - * other governmental approval, or letter of assurance, without first obtaining - * such license, approval or letter. - * - *****************************************************************************/ #include __FBSDID("$FreeBSD$"); @@ -171,7 +62,7 @@ #define EC_COMMAND_BURST_DISABLE ((EC_COMMAND) 0x83) #define EC_COMMAND_QUERY ((EC_COMMAND) 0x84) -/* +/* * EC_STATUS: * ---------- * The encoding of the EC status register is illustrated below. @@ -248,8 +139,7 @@ int ec_uid; ACPI_HANDLE ec_gpehandle; UINT8 ec_gpebit; - UINT8 ec_csrvalue; - + int ec_data_rid; struct resource *ec_data_res; bus_space_tag_t ec_data_tag; @@ -260,11 +150,11 @@ bus_space_tag_t ec_csr_tag; bus_space_handle_t ec_csr_handle; - struct mtx ec_mtx; int ec_glk; int ec_glkhandle; int ec_burstactive; int ec_sci_pend; + u_int ec_gencount; }; /* @@ -275,13 +165,10 @@ #define EC_LOCK_TIMEOUT 1000 /* Default delay in microseconds between each run of the status polling loop. */ -#define EC_POLL_DELAY 10 - -/* Default time in microseconds spent polling before sleep waiting. */ -#define EC_POLL_TIME 500 +#define EC_POLL_DELAY 5 /* Total time in ms spent waiting for a response from EC. */ -#define EC_TIMEOUT 500 +#define EC_TIMEOUT 750 #define EVENT_READY(event, status) \ (((event) == EC_EVENT_OUTPUT_BUFFER_FULL && \ @@ -298,17 +185,17 @@ TUNABLE_INT("debug.acpi.ec.burst", &ec_burst_mode); SYSCTL_INT(_debug_acpi_ec, OID_AUTO, burst, CTLFLAG_RW, &ec_burst_mode, 0, "Enable use of burst mode (faster for nearly all systems)"); -static int ec_poll_time = EC_POLL_TIME; -TUNABLE_INT("debug.acpi.ec.poll_time", &ec_poll_time); -SYSCTL_INT(_debug_acpi_ec, OID_AUTO, poll_time, CTLFLAG_RW, &ec_poll_time, - EC_POLL_TIME, "Time spent polling vs. sleeping (CPU intensive)"); +static int ec_polled_mode; +TUNABLE_INT("debug.acpi.ec.polled", &ec_polled_mode); +SYSCTL_INT(_debug_acpi_ec, OID_AUTO, polled, CTLFLAG_RW, &ec_polled_mode, 0, + "Force use of polled mode (only if interrupt mode doesn't work)"); static int ec_timeout = EC_TIMEOUT; 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 __inline ACPI_STATUS -EcLock(struct acpi_ec_softc *sc, int serialize) +static ACPI_STATUS +EcLock(struct acpi_ec_softc *sc) { ACPI_STATUS status; @@ -319,37 +206,27 @@ if (ACPI_FAILURE(status)) return (status); } - - /* - * If caller is executing a series of commands, acquire the exclusive lock - * to serialize with other users. - * To sync with bottom-half interrupt handler, always acquire the mutex. - */ - if (serialize) - ACPI_SERIAL_BEGIN(ec); - mtx_lock(&sc->ec_mtx); - + ACPI_SERIAL_BEGIN(ec); return (status); } -static __inline void +static void EcUnlock(struct acpi_ec_softc *sc) { - mtx_unlock(&sc->ec_mtx); - if (sx_xlocked(&ec_sxlock)) - ACPI_SERIAL_END(ec); + ACPI_SERIAL_END(ec); if (sc->ec_glk) AcpiReleaseGlobalLock(sc->ec_glkhandle); } static uint32_t EcGpeHandler(void *Context); -static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, +static ACPI_STATUS EcSpaceSetup(ACPI_HANDLE Region, UINT32 Function, void *Context, void **return_Context); static ACPI_STATUS EcSpaceHandler(UINT32 Function, ACPI_PHYSICAL_ADDRESS Address, UINT32 width, ACPI_INTEGER *Value, void *Context, void *RegionContext); -static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event); +static ACPI_STATUS EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, + u_int gen_count); static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd); static ACPI_STATUS EcRead(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data); @@ -387,10 +264,12 @@ MODULE_DEPEND(acpi_ec, acpi, 1, 1, 1); /* - * Look for an ECDT and if we find one, set up default GPE and + * Look for an ECDT and if we find one, set up default GPE and * space handlers to catch attempts to access EC space before * we have a real driver instance in place. - * TODO: if people report invalid ECDTs, add a tunable to disable them. + * + * TODO: Some old Gateway laptops need us to fake up an ECDT or + * otherwise attach early so that _REG methods can run. */ void acpi_ec_ecdt_probe(device_t parent) @@ -578,7 +457,6 @@ params = acpi_get_private(dev); sc->ec_dev = dev; sc->ec_handle = acpi_get_handle(dev); - mtx_init(&sc->ec_mtx, "ACPI EC lock", NULL, MTX_DEF); /* Retrieve previously probed values via device ivars. */ sc->ec_glk = params->glk; @@ -621,7 +499,7 @@ goto error; } - /* + /* * Install address space handler */ ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, "attaching address space handler\n")); @@ -656,12 +534,11 @@ AcpiRemoveAddressSpaceHandler(sc->ec_handle, ACPI_ADR_SPACE_EC, EcSpaceHandler); if (sc->ec_csr_res) - bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, + bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_csr_rid, sc->ec_csr_res); if (sc->ec_data_res) bus_release_resource(sc->ec_dev, SYS_RES_IOPORT, sc->ec_data_rid, sc->ec_data_res); - mtx_destroy(&sc->ec_mtx); return (ENXIO); } @@ -715,57 +592,52 @@ KASSERT(Context != NULL, ("EcGpeQueryHandler called with NULL")); /* Serialize user access with EcSpaceHandler(). */ - Status = EcLock(sc, TRUE); + Status = EcLock(sc); if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); + device_printf(sc->ec_dev, "GpeQuery lock error: %s\n", + AcpiFormatException(Status)); return; } /* * Send a query command to the EC to find out which _Qxx call it * wants to make. This command clears the SCI bit and also the - * interrupt source since we are edge-triggered. + * interrupt source since we are edge-triggered. To prevent the GPE + * that may arise from running the query from causing another query + * to be queued, we clear the pending flag only after running it. */ Status = EcCommand(sc, EC_COMMAND_QUERY); + sc->ec_sci_pend = FALSE; if (ACPI_FAILURE(Status)) { EcUnlock(sc); - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GPE query failed - %s\n", AcpiFormatException(Status)); - goto re_enable; + device_printf(sc->ec_dev, "GPE query failed: %s\n", + AcpiFormatException(Status)); + return; } Data = EC_GET_DATA(sc); - sc->ec_sci_pend = FALSE; - - /* Drop locks before evaluating _Qxx method since it may trigger GPEs. */ - EcUnlock(sc); /* Ignore the value for "no outstanding event". (13.3.5) */ - CTR2(KTR_ACPI, "ec query ok,%s running _Q%02x", Data ? "" : " not", Data); - if (Data == 0) - goto re_enable; + CTR2(KTR_ACPI, "ec query ok,%s running _Q%02X", Data ? "" : " not", Data); + if (Data == 0) { + EcUnlock(sc); + return; + } /* Evaluate _Qxx to respond to the controller. */ - snprintf(qxx, sizeof(qxx), "_Q%02x", Data); + snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); if (ACPI_FAILURE(Status) && Status != AE_NOT_FOUND) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "evaluation of GPE query method %s failed - %s\n", - qxx, AcpiFormatException(Status)); + device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", + qxx, AcpiFormatException(Status)); } -re_enable: - /* Re-enable the GPE event so we'll get future requests. */ - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeQueryHandler: AcpiEnableEvent failed\n"); + EcUnlock(sc); } /* - * Handle a GPE. Currently we only handle SCI events as others must - * be handled by polling in EcWaitEvent(). This is because some ECs - * treat events as level when they should be edge-triggered. + * The GPE handler is called when IBE/OBF or SCI events occur. We are + * called from an unknown lock context. */ static uint32_t EcGpeHandler(void *Context) @@ -773,68 +645,32 @@ struct acpi_ec_softc *sc = Context; ACPI_STATUS Status; EC_STATUS EcStatus; - int query_pend; KASSERT(Context != NULL, ("EcGpeHandler called with NULL")); + CTR0(KTR_ACPI, "ec gpe handler start"); /* - * Disable further GPEs while we handle this one. Since we are directly - * called by ACPI-CA and it may have unknown locks held, we specify the - * ACPI_ISR flag to keep it from acquiring any more mutexes (although - * sleeping would be ok since we're in an ithread.) + * Notify EcWaitEvent() that the status register is now fresh. If we + * didn't do this, it wouldn't be possible to distinguish an old IBE + * from a new one, for example when doing a write transaction (writing + * address and then data values.) */ - AcpiDisableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - - /* For interrupt (GPE) handler, don't acquire serialization lock. */ - Status = EcLock(sc, FALSE); - if (ACPI_FAILURE(Status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "GpeQuery lock error: %s\n", AcpiFormatException(Status)); - return (-1); - } + atomic_add_int(&sc->ec_gencount, 1); + wakeup(&sc->ec_gencount); /* - * If burst was active, but the status bit was cleared, the EC had to - * exit burst mode for some reason. Record this for later. + * If the EC_SCI bit of the status register is set, queue a query handler. + * It will run the query and _Qxx method later, under the lock. */ EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in query handler"); - sc->ec_burstactive = FALSE; - } - - /* - * If the EC_SCI bit of the status register is not set, then pass - * it along to any potential waiters as it may be an IBE/OBF event. - * If it is set, queue a query handler. - */ - query_pend = FALSE; - if ((EcStatus & EC_EVENT_SCI) == 0) { - CTR1(KTR_ACPI, "ec event was IBE/OBF, status %#x", EcStatus); - sc->ec_csrvalue = EcStatus; - wakeup(&sc->ec_csrvalue); - } else if (!sc->ec_sci_pend) { - /* SCI bit set and no pending query handler, so schedule one. */ - CTR0(KTR_ACPI, "ec queueing gpe handler"); + if ((EcStatus & EC_EVENT_SCI) && !sc->ec_sci_pend) { + CTR0(KTR_ACPI, "ec gpe queueing query handler"); Status = AcpiOsExecute(OSL_GPE_HANDLER, EcGpeQueryHandler, Context); - if (ACPI_SUCCESS(Status)) { + if (ACPI_SUCCESS(Status)) sc->ec_sci_pend = TRUE; - query_pend = TRUE; - } else - printf("Queuing GPE query handler failed.\n"); - } - - /* - * If we didn't queue a query handler, which will eventually re-enable - * the GPE, re-enable it right now so we can get more events. - */ - if (!query_pend) { - Status = AcpiEnableGpe(sc->ec_gpehandle, sc->ec_gpebit, ACPI_ISR); - if (ACPI_FAILURE(Status)) - printf("EcGpeHandler: AcpiEnableGpe failed\n"); + else + printf("EcGpeHandler: queuing GPE query handler failed\n"); } - - EcUnlock(sc); return (0); } @@ -878,8 +714,19 @@ EcAddr = Address; Status = AE_ERROR; - /* Grab serialization lock to hold across command sequence. */ - Status = EcLock(sc, TRUE); + /* + * If booting, check if we need to run the query handler. If so, we + * we call it directly here since our thread taskq is not active yet. + */ + if (cold || rebooting) { + if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { + CTR0(KTR_ACPI, "ec running gpe handler directly"); + EcGpeQueryHandler(sc); + } + } + + /* Serialize with EcGpeQueryHandler() at transaction granularity. */ + Status = EcLock(sc); if (ACPI_FAILURE(Status)) return_ACPI_STATUS (Status); @@ -910,83 +757,119 @@ } static ACPI_STATUS -EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event) +EcCheckStatus(struct acpi_ec_softc *sc, const char *msg, EC_EVENT event) +{ + ACPI_STATUS status; + EC_STATUS ec_status; + + status = AE_NO_HARDWARE_RESPONSE; + ec_status = EC_GET_CSR(sc); + if (sc->ec_burstactive && !(ec_status & EC_FLAG_BURST_MODE)) { + CTR1(KTR_ACPI, "ec burst disabled in waitevent (%s)", msg); + sc->ec_burstactive = FALSE; + } + if (EVENT_READY(event, ec_status)) { + CTR2(KTR_ACPI, "ec %s wait ready, status %#x", msg, ec_status); + status = AE_OK; + } + return (status); +} + +static ACPI_STATUS +EcWaitEvent(struct acpi_ec_softc *sc, EC_EVENT Event, u_int gen_count) { - EC_STATUS EcStatus; ACPI_STATUS Status; - int count, i, retval, slp_ival; + int count, i, slp_ival; ACPI_SERIAL_ASSERT(ec); Status = AE_NO_HARDWARE_RESPONSE; - EcStatus = 0; /* - * Poll for up to ec_poll_time microseconds since many ECs complete - * the command quickly, especially if in burst mode. - */ -#if 0 /* Enable this as a possible workaround if EC times out. */ - AcpiOsStall(EC_POLL_DELAY); -#endif - count = ec_poll_time / EC_POLL_DELAY; - if (count <= 0) - count = 1; - for (i = 0; i < count; i++) { - EcStatus = EC_GET_CSR(sc); - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (poll)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec poll wait ready, status %#x", EcStatus); - Status = AE_OK; - break; + * The main CPU should be much faster than the EC. So the status should + * be "not ready" when we start waiting. But if the main CPU is really + * slow, it's possible we see the current "ready" response. Since that + * can't be distinguished from the previous response in polled mode, + * this is a potential issue. We really should have interrupts enabled + * during boot so there is no ambiguity in polled mode. + * + * If this occurs, we add an additional delay before actually entering + * the status checking loop, hopefully to allow the EC to go to work + * and produce a non-stale status. + */ + if (cold || rebooting || ec_polled_mode) { + static int once; + + if (EcCheckStatus(sc, "pre-check", Event) == AE_OK) { + if (!once) { + device_printf(sc->ec_dev, + "warning: EC done before starting event wait\n"); + once = 1; + } + AcpiOsStall(10); } - AcpiOsStall(EC_POLL_DELAY); } - /* - * If we still don't have a response and we're up and running, wait up - * to ec_timeout ms for completion, sleeping for chunks of 1 ms or the - * smallest resolution hz supports. - */ - slp_ival = 0; - if (Status != AE_OK) { - retval = ENXIO; - if (!cold) { - slp_ival = hz / 1000; - if (slp_ival != 0) { - count = ec_timeout / slp_ival; - } else { - /* hz has less than 1000 Hz resolution so scale timeout. */ - slp_ival = 1; - count = ec_timeout / (1000 / hz); - } - } else - count = ec_timeout; + /* Wait for event by polling or GPE (interrupt). */ + if (cold || rebooting || ec_polled_mode) { + count = (ec_timeout * 1000) / EC_POLL_DELAY; + if (count <= 0) + count = 1; for (i = 0; i < count; i++) { - if (retval != 0) - EcStatus = EC_GET_CSR(sc); - else - EcStatus = sc->ec_csrvalue; - if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { - CTR0(KTR_ACPI, "ec burst disabled in waitevent (slp)"); - sc->ec_burstactive = FALSE; - } - if (EVENT_READY(Event, EcStatus)) { - CTR1(KTR_ACPI, "ec sleep wait ready, status %#x", EcStatus); - Status = AE_OK; + Status = EcCheckStatus(sc, "poll", Event); + if (Status == AE_OK) break; + AcpiOsStall(EC_POLL_DELAY); + } + } else { + slp_ival = hz / 1000; + if (slp_ival != 0) { + count = ec_timeout / slp_ival; + } else { + /* hz has less than 1000 Hz resolution so scale timeout. */ + slp_ival = 1; + count = ec_timeout / (1000 / hz); + } + + /* + * Wait for the GPE to signal the status changed, checking the + * status register each time we get one. It's possible to get a + * GPE for an event we're not interested in here (i.e., SCI for + * EC query). + */ + for (i = 0; i < count; i++) { + if (gen_count != sc->ec_gencount) { + /* + * Record new generation count. It's possible the GPE was + * just to notify us that a query is needed and we need to + * wait for a second GPE to signal the completion of the + * event we are actually waiting for. + */ + gen_count = sc->ec_gencount; + Status = EcCheckStatus(sc, "sleep", Event); + if (Status == AE_OK) + break; } - if (!cold) { - retval = msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", - slp_ival); - } else - AcpiOsStall(1000); + tsleep(&sc->ec_gencount, PZERO, "ecgpe", slp_ival); } - } + /* + * We finished waiting for the GPE and it never arrived. Try to + * read the register once and trust whatever value we got. This is + * the best we can do at this point. Then, force polled mode on + * since this system doesn't appear to generate GPEs. + */ + if (Status != AE_OK) { + Status = EcCheckStatus(sc, "sleep_end", Event); + device_printf(sc->ec_dev, + "wait timed out (%sresponse), forcing polled mode\n", + Status == AE_OK ? "" : "no "); + ec_polled_mode = TRUE; + } + } + if (Status != AE_OK) + CTR0(KTR_ACPI, "error: ec wait timed out"); return (Status); -} +} static ACPI_STATUS EcCommand(struct acpi_ec_softc *sc, EC_COMMAND cmd) @@ -994,6 +877,7 @@ ACPI_STATUS status; EC_EVENT event; EC_STATUS ec_status; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); @@ -1013,15 +897,15 @@ event = EC_EVENT_OUTPUT_BUFFER_FULL; break; default: - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: Invalid command %#x\n", cmd); + device_printf(sc->ec_dev, "EcCommand: invalid command %#x\n", cmd); return (AE_BAD_PARAMETER); } /* Run the command and wait for the chosen event. */ CTR1(KTR_ACPI, "ec running command %#x", cmd); + gen_count = sc->ec_gencount; EC_SET_CSR(sc, cmd); - status = EcWaitEvent(sc, event); + status = EcWaitEvent(sc, event, gen_count); if (ACPI_SUCCESS(status)) { /* If we succeeded, burst flag should now be present. */ if (cmd == EC_COMMAND_BURST_ENABLE) { @@ -1029,11 +913,8 @@ if ((ec_status & EC_FLAG_BURST_MODE) == 0) status = AE_ERROR; } - } else { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcCommand: no response to %#x\n", cmd); - } - + } else + device_printf(sc->ec_dev, "EcCommand: no response to %#x\n", cmd); return (status); } @@ -1042,6 +923,7 @@ { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR1(KTR_ACPI, "ec read from %#x", Address); @@ -1060,32 +942,32 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL); + status = EcWaitEvent(sc, EC_EVENT_OUTPUT_BUFFER_FULL, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to send data.\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting to get data\n"); return (status); } - *Data = EC_GET_DATA(sc); if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } return (AE_OK); -} +} static ACPI_STATUS EcWrite(struct acpi_ec_softc *sc, UINT8 Address, UINT8 *Data) { ACPI_STATUS status; UINT8 data; + u_int gen_count; ACPI_SERIAL_ASSERT(ec); CTR2(KTR_ACPI, "ec write to %#x, data %#x", Address, *Data); @@ -1104,27 +986,27 @@ if (ACPI_FAILURE(status)) return (status); + gen_count = sc->ec_gencount; EC_SET_DATA(sc, Address); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcRead: Failed waiting for EC to process address\n"); + device_printf(sc->ec_dev, "EcRead: failed waiting for sent address\n"); return (status); } + gen_count = sc->ec_gencount; EC_SET_DATA(sc, *Data); - status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY); + status = EcWaitEvent(sc, EC_EVENT_INPUT_BUFFER_EMPTY, gen_count); if (ACPI_FAILURE(status)) { - ACPI_VPRINT(sc->ec_dev, acpi_device_get_parent_softc(sc->ec_dev), - "EcWrite: Failed waiting for EC to process data\n"); + device_printf(sc->ec_dev, "EcWrite: failed waiting for sent data\n"); return (status); } if (sc->ec_burstactive) { + sc->ec_burstactive = FALSE; status = EcCommand(sc, EC_COMMAND_BURST_DISABLE); if (ACPI_FAILURE(status)) return (status); - sc->ec_burstactive = FALSE; CTR0(KTR_ACPI, "ec disabled burst ok"); } --------------010202030307050802010105-- From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 18:36:59 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C4716A421 for ; Tue, 11 Sep 2007 18:36:59 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA7C13C45D for ; Tue, 11 Sep 2007 18:36:58 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1276461nfb for ; Tue, 11 Sep 2007 11:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=owsz9Em0sDOYVMW4Tyxtyvii6l+J/b7k+L5Tb/tMM2g=; b=I8SvoaFRVYsTQ6q5a9R+5gOy1FOA1wdzE3g/CF63Grm/4d0DyVd6Qp6O0x5IdN2yGz1mNRAITK/zQIOs34GeDeRUH3mdsKIZYxLQ2pCzhlAPmcHA9F2fx1aAU7AGmk3JnFlrQsm9dJq6CFr1bBsDidvjB50FEOnJW3ex/lebe/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hnFm/YXuvc02GIOlfPat3+ssx/S9l5IysFWfqyo5gyAo4Za+4ALwUx9VwdDBwq57AeUlvp07Bm+WmcK/k/S99j8nk/fwc4uqbtN3bWNngh9vei7dJgt8mRr7hk0z9pELcWb+HxunCiu82XXDCdc30BLuuwBesHitwVO44gYS0hk= Received: by 10.86.80.5 with SMTP id d5mr4812113fgb.1189535817580; Tue, 11 Sep 2007 11:36:57 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Tue, 11 Sep 2007 11:36:57 -0700 (PDT) Message-ID: <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> Date: Tue, 11 Sep 2007 22:36:57 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709111201.39306.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709101101.03340.jkim@FreeBSD.org> <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> <200709111201.39306.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 18:36:59 -0000 On 9/11/07, Jung-uk Kim wrote: > > I tried it with src from September 10, without patch from Nate. > > Can you try it with his patch as well? Sure, I will do it. > > When I tried it without acfreebsd.h patch, kernel didn't compile. > > That is strange because I can compile kernel with or without it. In > fact, I have been using it without the acfreebsd.h patch for > months. :-( I got next error: --- cc -O -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:237: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:237: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:238: error: conflicting types for 'AcpiOsCreateSemaphore' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:93: error: previous definition of 'AcpiOsCreateSemaphore' was here /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:261: error: expected identifier or '(' before 'void' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:277: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:278: error: conflicting types for 'AcpiOsWaitSemaphore' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:142: error: previous definition of 'AcpiOsWaitSemaphore' was here /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:321: error: expected identifier or '(' before 'void' *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. *** Error code 1 Stop in /usr/src/sys/modules/acpi. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 --- > > When I tried it with acfreebsd.h patch kernel compiled, but I > > couldn't boot with ACPI - got kernel panic... > > Can you describe the panic messages? I got next message on the console: --- panic: blockable sleep lock (sleep mutex) ACPI EC lock @ /usr/src/sys/modules/acpi/acpi/../../dev/acpica/acpi_ec.c:330 cpuid = 0 KDB: enter: panic [thread pid 21 tid 100013 ] Stopped at kdb_enter+0x32: leave db> --- Unfortunatly, I do not have experience in debugging, but If there anything I can help - I'm more than eager to do it. Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 18:54:09 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5F8916A417 for ; Tue, 11 Sep 2007 18:54:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 955BA13C4D0 for ; Tue, 11 Sep 2007 18:54:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8BIs84B047594; Tue, 11 Sep 2007 14:54:08 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Tue, 11 Sep 2007 14:54:04 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709111201.39306.jkim@FreeBSD.org> <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> In-Reply-To: <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709111454.05746.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 18:54:10 -0000 On Tuesday 11 September 2007 02:36 pm, Denis wrote: > On 9/11/07, Jung-uk Kim wrote: > > > I tried it with src from September 10, without patch from Nate. > > > > Can you try it with his patch as well? > > Sure, I will do it. Thanks. > > > When I tried it without acfreebsd.h patch, kernel didn't > > > compile. > > > > That is strange because I can compile kernel with or without it. > > In fact, I have been using it without the acfreebsd.h patch for > > months. :-( > > I got next error: > --- > cc -O -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g > -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse > -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > -fformat-extensions -c > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >37: error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >37: error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >38: error: conflicting types for 'AcpiOsCreateSemaphore' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:9 >3: error: previous definition of 'AcpiOsCreateSemaphore' was here > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >61: error: expected identifier or '(' before 'void' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >77: error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:2 >78: error: conflicting types for 'AcpiOsWaitSemaphore' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:1 >42: error: previous definition of 'AcpiOsWaitSemaphore' was here > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:3 >21: error: expected identifier or '(' before 'void' > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > --- OsdSynch.c may have been corrupt. Can you revert the three files, download the patch again from the URL, re-apply, and recompile? > > > When I tried it with acfreebsd.h patch kernel compiled, but I > > > couldn't boot with ACPI - got kernel panic... > > > > Can you describe the panic messages? > > I got next message on the console: > --- > panic: blockable sleep lock (sleep mutex) ACPI EC lock @ > /usr/src/sys/modules/acpi/acpi/../../dev/acpica/acpi_ec.c:330 > cpuid = 0 > KDB: enter: panic > [thread pid 21 tid 100013 ] > Stopped at kdb_enter+0x32: leave > db> > --- I believe Nate's patch should fix the problem. Jung-uk Kim > Unfortunatly, I do not have experience in debugging, but If there > anything I can help - I'm more than eager to do it. > > Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 18:56:46 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F0AC16A41A for ; Tue, 11 Sep 2007 18:56:46 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1B15513C483 for ; Tue, 11 Sep 2007 18:56:46 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 81849 invoked from network); 11 Sep 2007 18:56:46 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 11 Sep 2007 18:56:46 -0000 Message-ID: <46E6E4E9.4040900@root.org> Date: Tue, 11 Sep 2007 11:56:41 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Denis References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709101101.03340.jkim@FreeBSD.org> <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> <200709111201.39306.jkim@FreeBSD.org> <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> In-Reply-To: <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Jung-uk Kim Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 18:56:46 -0000 Denis wrote: > On 9/11/07, Jung-uk Kim wrote: >>> I tried it with src from September 10, without patch from Nate. >> Can you try it with his patch as well? > > Sure, I will do it. > >>> When I tried it without acfreebsd.h patch, kernel didn't compile. >> That is strange because I can compile kernel with or without it. In >> fact, I have been using it without the acfreebsd.h patch for >> months. :-( > > I got next error: > --- > cc -O -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc > -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g > -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:237: > error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:237: > error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:238: > error: conflicting types for 'AcpiOsCreateSemaphore' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:93: > error: previous definition of 'AcpiOsCreateSemaphore' was here > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:261: > error: expected identifier or '(' before 'void' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:277: > error: expected declaration specifiers or '...' before numeric > constant > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:278: > error: conflicting types for 'AcpiOsWaitSemaphore' > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:142: > error: previous definition of 'AcpiOsWaitSemaphore' was here > /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:321: > error: expected identifier or '(' before 'void' > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 Are you running 7-current? >>> When I tried it with acfreebsd.h patch kernel compiled, but I >>> couldn't boot with ACPI - got kernel panic... >> Can you describe the panic messages? > > I got next message on the console: > --- > panic: blockable sleep lock (sleep mutex) ACPI EC lock @ > /usr/src/sys/modules/acpi/acpi/../../dev/acpica/acpi_ec.c:330 > cpuid = 0 > KDB: enter: panic > [thread pid 21 tid 100013 ] > Stopped at kdb_enter+0x32: leave > db> My EC diff (latest posted here was ecng-{6,7}c.diff) fixes this problem. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Sep 11 21:49:22 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9865716A421 for ; Tue, 11 Sep 2007 21:49:22 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6B30A13C47E for ; Tue, 11 Sep 2007 21:49:22 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1433rvb for ; Tue, 11 Sep 2007 14:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=mI6Q26WxmzN9GYHbYTI6HUXKgnbud09uR/N16yq6Fnw=; b=A3GI4si7iCuzcuiw2XmnLvsLQi9zMWGLuuYoGM48U8Z61kgknS/kN0gNPJOPSbgL1g4keQJabxtaU1C/Wboew2PQV3fJfHOlzGV8ZXncMyMKmxn2PruhUSYFuCK1U8BmmqynqwqSJIDClos8ybXWto6z093mgs9lTLr4/ZgSW/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dnU6eicpXGtC9TsrAN2y2drGOEeGvd2poLQr4VoYBXZsVpwLIbv5dx3QP59KSL7KOlGTmoNQiK6rWeplQaBTIK9MCmPKuVFMePjzrJKAcqhCGQORcRCRcEcWjEvw2PbNnF2nbfeNBR+QKWLSkM+UwLXZS7SkmVDLhtTyGOYp9fg= Received: by 10.140.133.10 with SMTP id g10mr2600351rvd.1189547361745; Tue, 11 Sep 2007 14:49:21 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Tue, 11 Sep 2007 14:49:21 -0700 (PDT) Message-ID: <632825b40709111449uf8e184cv2623b052d6013b82@mail.gmail.com> Date: Tue, 11 Sep 2007 18:49:21 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <46E6DF34.1060304@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> <46E6DF34.1060304@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2007 21:49:22 -0000 On 9/11/07, Nate Lawson wrote: > > William Grzybowski wrote: > > On 9/6/07, *Nate Lawson* > wrote: > > > > Nate Lawson wrote: > > > I've done some major rework on the EC driver. This should help > with > > > various problems, including timeouts while checking battery status > or > > > temperature. The attached patches are for 6.x and 7.x. Please > > test and > > > let me know if you get any new errors on dmesg or if it fixes > > things for > > > you (especially HP/Compaq laptop owners). > > > > > > If you still have problems, try setting each of these tunables > > > individually and then both together (i.e., in > > /boot/loader.conf). Note > > > that this will be four (4) test runs total, so don't just set both > and > > > say it doesn't work. > > > > > > debug.acpi.ec.burst= "1" > > > debug.acpi.ec.polled="1" > > > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, > no > > > problems in either regular or burst mode. > > > > > > > > > Commit message: > > > Rewrite the EC driver event model. The main goal is to avoid > > > polling/interrupt-driven fallback and instead use polling only > during > > > boot and pure interrupt-driven mode after boot. Polled mode could > be > > > relegated completely to a legacy role if we could enable > interrupts > > > during boot. Polled mode can be forced after boot by setting > > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > > > One minor note -- power off shutdown (shutdown/halt -p) is turned > into a > > (safe) reboot with this patch. I have tested the fix, which is just > to > > force polled mode during shutdown as well. I don't have time to > > re-roll > > the patch today but will send tomorrow. > > > > Please test the patch as posted, ignoring that minor issue. The > test > > results during normal use are still valid. > > > > > > Hi Nate, > > > > I tested this patch on my acer notebook (intel chipset) and i did not > > notice any changes, unless some errors on dmesg, like: > > acpi_ec0: EcCommand: no response to 0x84 > > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > > acpi_ec0: EcCommand: no response to 0x82 > > acpi_ec0: EcCommand: no response to 0x80 > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE > > As I noted before, your system enters the poll loop with the status > appearing to be already complete. Can you get back to me on my previous > questions, especially whether forcing polled mode works for you? I > didn't see any errors in that dmesg case. > > I've updated the patches to do one final check if the interrupt-driven > mode gets a timeout. If the status is complete, it will force the > system back into polled mode since interrupt mode doesn't work. It also > has a case for polled mode during boot where the status appears to be > already complete. It waits a short while before actually checking the > status, just in case the EC is really slow and hasn't gotten to work on > the new request yet. > > Give it a try also, with no tunables set. > Hi, Unfortunelly I don't had time to complete the tests which you asked to, i got a lot of work ;(. Tomorrow I will use my free time to do it all and the new ones. Thanks Nate. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 12 05:15:58 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B843116A418 for ; Wed, 12 Sep 2007 05:15:58 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2245913C48A for ; Wed, 12 Sep 2007 05:15:57 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so79018nfb for ; Tue, 11 Sep 2007 22:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RD/P2An80RtyEkoiFh+JtVO2uWtdkfuxfCRCpL8j63E=; b=naG/WMPEjBDhj6bTXJ5Bvx4fUa2ID9ekaCnpRm+yx6ITLkaT59a8E0TZQpT8BGr2PM1b9aYUDxLVZXGu24Ay6i2NFnUeLys0PJ6Q1yHp9UreFt8AL0TVbNw+4anT86i2Sn7bvuberh4qAYuS8u6+0a7YjOHhWZ/K6b4qw/AVGxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IjqDhjR9zkBb7pWH8TsG8Gwj3SXFURCOW6YCAOboIa+FSnYBOlELKT4L5hongV8Tsie6We1NXYJBtPD7pWElWfls3oputt3MJOcqqzgUco0u8yhQvrWNa2VAZ6swGZ/RKxfj2oJJ/TDSOxFlyTKk3ZQq1eYKcFA3fQYZ4xr+LzU= Received: by 10.86.98.18 with SMTP id v18mr5119593fgb.1189574156819; Tue, 11 Sep 2007 22:15:56 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Tue, 11 Sep 2007 22:15:56 -0700 (PDT) Message-ID: <325305250709112215o5b26f3fbj1522413689b1ff6f@mail.gmail.com> Date: Wed, 12 Sep 2007 09:15:56 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709111454.05746.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709111201.39306.jkim@FreeBSD.org> <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> <200709111454.05746.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 05:15:58 -0000 > > > That is strange because I can compile kernel with or without it. > > > In fact, I have been using it without the acfreebsd.h patch for > > > months. :-( > > > OsdSynch.c may have been corrupt. Can you revert the three files, > download the patch again from the URL, re-apply, and recompile? Yes, I did it. Patch, that you sent me directly have different size than that your gave a link. I revert all files back, downloaded patch from the link, patched all but acfreebsd.h and got next error: --- cc -O -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/usr/src/sys/modules/acpi/acpi/../../../contrib/dev/acpica -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:254: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:254: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:255: error: conflicting types for 'AcpiOsCreateSemaphore' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:93: error: previous definition of 'AcpiOsCreateSemaphore' was here /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:278: error: expected identifier or '(' before 'void' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:294: error: expected declaration specifiers or '...' before numeric constant /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:295: error: conflicting types for 'AcpiOsWaitSemaphore' /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:142: error: previous definition of 'AcpiOsWaitSemaphore' was here /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/Osd/OsdSynch.c:338: error: expected identifier or '(' before 'void' *** Error code 1 Stop in /usr/src/sys/modules/acpi/acpi. *** Error code 1 Stop in /usr/src/sys/modules/acpi. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --- But when I patched all 3 files, kernel compiled fine, but I got another kernel panic (see next mail) Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 12 05:28:24 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CA8116A419 for ; Wed, 12 Sep 2007 05:28:24 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 00A6813C48A for ; Wed, 12 Sep 2007 05:28:23 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so121286mue for ; Tue, 11 Sep 2007 22:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Uk5rHMwbAHUW/tyxlGSkPOhoMn+LnP9ttYT76OXiH3M=; b=Q7wF5aUzMLsHTUs/+yWp5fnAO9Z4OzYfZO5H0KkO1vhgqsQJgJ0WVX+S2xYLpY/kBafMux3kgISsU01n9jIfLOE4DRXBGYLVKVDRDfCO6dlp2QfUekxibYKx/QOY+suNfb13JHEZMDzp9LY7hBuT5AXoiXrm+eVRKSp00R2vWx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jp2fFlp5SddKzdSlMmvJERNxqSkKUyPL+QzlMpaBq1shtTDfCiKHhad2f3OEt+KAlBQTTSIZmBucOZ/h5gLAKMnp0R9xZ4AeGxT/MxzqNQsB6UAedF//eDNRFK1tdtgghd0Oi0Y3bSL7I9bf3JzHZEmC7czP0yFWJGD93NM/6xw= Received: by 10.86.1.1 with SMTP id 1mr5150163fga.1189574902850; Tue, 11 Sep 2007 22:28:22 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Tue, 11 Sep 2007 22:28:22 -0700 (PDT) Message-ID: <325305250709112228w64e2f927v2bc46aa73e49bb17@mail.gmail.com> Date: Wed, 12 Sep 2007 09:28:22 +0400 From: Denis To: "Nate Lawson" In-Reply-To: <46E6E4E9.4040900@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709101101.03340.jkim@FreeBSD.org> <325305250709102224n5e626590g83f6482747efae9d@mail.gmail.com> <200709111201.39306.jkim@FreeBSD.org> <325305250709111136o737a176bufdd06bfeff377fc@mail.gmail.com> <46E6E4E9.4040900@root.org> Cc: freebsd-acpi@freebsd.org, Jung-uk Kim Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 05:28:24 -0000 On 9/11/07, Nate Lawson wrote: > Are you running 7-current? Yes, I'm running 7-current. > > I got next message on the console: > > --- > > panic: blockable sleep lock (sleep mutex) ACPI EC lock @ > > /usr/src/sys/modules/acpi/acpi/../../dev/acpica/acpi_ec.c:330 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 21 tid 100013 ] > > Stopped at kdb_enter+0x32: leave > > db> > > My EC diff (latest posted here was ecng-{6,7}c.diff) fixes this problem. I applied your patch ecng-7c.diff and Jung-uk Kim, compiled kernel, but got next kernel panic: --- panic: blockable sleep lock (sleep mutex) 32 @ /usr/src/sys/vm/uma_core.c:1830 cpuid = 0 KDB: enter: panic [thread pid 21 tid 100013 ] Stopped at kdb_enter+0x32: leave --- And sorry for delay in answers. This is because to be sure I recompile kernel each time (with command /usr/src && make buildkernel KERNCONF=GENERIC). If there is any way I can speed up this process and be safe? Best regards, Denis From owner-freebsd-acpi@FreeBSD.ORG Wed Sep 12 23:27:50 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F51516A417 for ; Wed, 12 Sep 2007 23:27:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 1289B13C465 for ; Wed, 12 Sep 2007 23:27:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8CNRnd1046744; Wed, 12 Sep 2007 19:27:49 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Wed, 12 Sep 2007 19:27:42 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E6E4E9.4040900@root.org> <325305250709112228w64e2f927v2bc46aa73e49bb17@mail.gmail.com> In-Reply-To: <325305250709112228w64e2f927v2bc46aa73e49bb17@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709121927.46465.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4260/Wed Sep 12 18:12:31 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 23:27:50 -0000 On Wednesday 12 September 2007 01:28 am, Denis wrote: > I applied your patch ecng-7c.diff and Jung-uk Kim, compiled kernel, > but got next kernel panic: > --- > panic: blockable sleep lock (sleep mutex) 32 @ > /usr/src/sys/vm/uma_core.c:1830 cpuid = 0 > KDB: enter: panic > [thread pid 21 tid 100013 ] > Stopped at kdb_enter+0x32: leave > --- Please remove spinlock_enter() and spinlock_exit() from OsdSynch.c and retry. > And sorry for delay in answers. This is because to be sure I > recompile kernel each time (with command /usr/src && make > buildkernel KERNCONF=GENERIC). If there is any way I can speed up > this process and be safe? rm -rf /usr/src/sys//compile/GENERIC cd /usr/src/sys//conf config GENERIC cd ../compile/GENERIC make depend make make install Once that is done, you can just repeat: cd /usr/src/sys//compile/GENERIC make make install if only one or two files are changed. It is not always safe but it usually works. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 13 01:39:46 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47AA616A417 for ; Thu, 13 Sep 2007 01:39:46 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 35AEB13C458 for ; Thu, 13 Sep 2007 01:39:46 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 37593 invoked from network); 13 Sep 2007 01:39:47 -0000 Received: from 209-128-117-003.bayarea.net (HELO ?10.0.1.144?) (nate-mail@209.128.117.3) by root.org with ESMTPA; 13 Sep 2007 01:39:47 -0000 Message-ID: <46E894DC.6020707@root.org> Date: Wed, 12 Sep 2007 18:39:40 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Mikael Ikivesi References: <46E0777A.8070901@root.org> <200709081054.14073.mikael.ikivesi@pp.inet.fi> In-Reply-To: <200709081054.14073.mikael.ikivesi@pp.inet.fi> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 01:39:46 -0000 Mikael Ikivesi wrote: > On Friday 07 September 2007 00:56, Nate Lawson wrote: >> I've done some major rework on the EC driver. This should help with >> various problems, including timeouts while checking battery status or >> temperature. > > > And it does :) Thanks... > > It took away those error messages I was having. Now things seems to work, more > or less... > > dmesg still shows this: > acpi0: reservation of 0, 1000 (3) failed > > but thats all. > When issuing halt -p the system powersoff but show some acpi related message > just before powering off but it goes so fast I dont have a clue about its > contents. > > > > > Note still: If I try to suspend machine I get kernel panic. I dont know if it > was you patch or some other update, but before I got only messages and bounce > back to system without crashing. Because of the updates I cannot now access > the messages but if I remember correctly they were something about: > device physically ejected? and they had something to do with cardbus if I > remember correctly... > ...sorry for being so vague! > > > BUT about that panic I can be more precise :) > > > acpi_button0: sleep button pressed > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex ACPI global lock r = 0 (0xffffffff808ac4a0) locked > @ /usr/src/sys/dev/acpica/acpi.c:2222 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > witness_warn() at witness_warn+0x248 > trap() at trap+0x25e > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff801d9cf4, rsp = 0xffffffff9ed4aa00, rbp = > 0xffffffff9ed4aa30 --- > acpi_AckSleepState() at acpi_AckSleepState+0x34 > devfs_ioctl_f() at devfs_ioctl_f+0x6d > kern_ioctl() at kern_ioctl+0xa3 > ioctl() at ioctl+0xf9 > syscall() at syscall+0x1ce > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8007187ec, rsp = > 0x7fffffffecd8, rbp = 0x7fffffffee50 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff801d9cf4 > stack pointer = 0x10:0xffffffff9ed4aa00 > frame pointer = 0x10:0xffffffff9ed4aa30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 748 (acpiconf) > Fixed, thanks. -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 13 01:50:06 2007 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1E516A41A for ; Thu, 13 Sep 2007 01:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 781D213C457 for ; Thu, 13 Sep 2007 01:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8D1o6UC046066 for ; Thu, 13 Sep 2007 01:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8D1o6Ca046065; Thu, 13 Sep 2007 01:50:06 GMT (envelope-from gnats) Date: Thu, 13 Sep 2007 01:50:06 GMT Message-Id: <200709130150.l8D1o6Ca046065@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Nate Lawson Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nate Lawson List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 01:50:06 -0000 The following reply was made to PR kern/108581; it has been noted by GNATS. From: Nate Lawson To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 12 Sep 2007 18:42:06 -0700 Can you send the output of: sysctl dev.cpu sysctl hw.acpi -Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 13 17:59:29 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE59916A41B for ; Thu, 13 Sep 2007 17:59:29 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 7457C13C46A for ; Thu, 13 Sep 2007 17:59:29 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so553215nfb for ; Thu, 13 Sep 2007 10:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=K9qS+Nv9qosczSINM+HNLTD66CNyrszY3rdLpeaXDi8=; b=eiQXmdl5sy/9iKZ/syJGFapTH7TFy0ImBf1fbnbrfBbrX3VqTWOGtEXAp80lKgeXf/Ixm9ET1ZyW4mq9bDhC0yaTS92EeBb9OTgY5z1i+iV+ZbCCoPbSoJtuaoaLK5jhZFpmZoN7wLBnAg3jl5KPC7sfWxfSKXEOYv8r/SyinJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cTLsyHiUVj8tQ6eatf0fHOOePd2ZUBN1nxVkuBRDygkwFK8rI/crh7/irYaV1dx5ksVVdX2pqg7F4Jh0S1uKJTC1yprFPrUxHtoSGDtX7Xj/wEFZCNT2a1+SQYb1YnNL3wdz+nxs02QfEQFKxye7QGoqLd6nNfCp7iyEvf3Nm2g= Received: by 10.86.70.8 with SMTP id s8mr706527fga.1189706368022; Thu, 13 Sep 2007 10:59:28 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Thu, 13 Sep 2007 10:59:27 -0700 (PDT) Message-ID: <325305250709131059g6b73cf51o9dc9e09d7e0c2800@mail.gmail.com> Date: Thu, 13 Sep 2007 21:59:27 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709121927.46465.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <46E6E4E9.4040900@root.org> <325305250709112228w64e2f927v2bc46aa73e49bb17@mail.gmail.com> <200709121927.46465.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 17:59:30 -0000 On 9/13/07, Jung-uk Kim wrote: > Please remove spinlock_enter() and spinlock_exit() from OsdSynch.c and > retry. So I applied your patch, Nate's patch, removed spinlock_enter() and spinlock_exit() from OsdSynch.c and tried to to play a little with booting with ACPI: For the first time I could boot with ACPI and login to the system. But after several minutes I was unable to enter any symbol from the keyboard, however was able to switch between consoles (alt+Fx). Couple times got kernel panic: --- panic: _sx_xlock_hard: recursed on non recursive sx ACPI embedded controller @ /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:209 cpuid = 0 KDB: enter: panic [thread: pid 8 tid 100018 ] Stopped at kbd_enter+0x32: leave db> --- and couple time booting process stops at the different stages (but before the login prompt), I was able to print from keyboard, symbols appeared at the screen, however system did not do anything except this. There were no errors in the logs (console.log, messages) > rm -rf /usr/src/sys//compile/GENERIC > cd /usr/src/sys//conf > config GENERIC > cd ../compile/GENERIC > make depend > make > make install > > Once that is done, you can just repeat: > > cd /usr/src/sys//compile/GENERIC > make > make install > > if only one or two files are changed. It is not always safe but it > usually works. Many-many thanks :-)! Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 13 18:16:26 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C1B216A417 for ; Thu, 13 Sep 2007 18:16:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id DE3B113C468 for ; Thu, 13 Sep 2007 18:16:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8DIGNHt012869; Thu, 13 Sep 2007 14:16:24 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Thu, 13 Sep 2007 14:16:18 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709121927.46465.jkim@FreeBSD.org> <325305250709131059g6b73cf51o9dc9e09d7e0c2800@mail.gmail.com> In-Reply-To: <325305250709131059g6b73cf51o9dc9e09d7e0c2800@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709131416.21302.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4264/Thu Sep 13 02:06:05 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 18:16:26 -0000 On Thursday 13 September 2007 01:59 pm, Denis wrote: > On 9/13/07, Jung-uk Kim wrote: > > Please remove spinlock_enter() and spinlock_exit() from > > OsdSynch.c and retry. > > So I applied your patch, Nate's patch, removed spinlock_enter() and > spinlock_exit() from OsdSynch.c and tried to to play a little with > booting with ACPI: > For the first time I could boot with ACPI and login to the system. > But after several minutes I was unable to enter any symbol from the > keyboard, however was able to switch between consoles (alt+Fx). > > Couple times got kernel panic: > --- > panic: _sx_xlock_hard: recursed on non recursive sx ACPI embedded > controller @ > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:209 > > cpuid = 0 > KDB: enter: panic > [thread: pid 8 tid 100018 ] > Stopped at kbd_enter+0x32: leave > db> > --- > > and couple time booting process stops at the different stages (but > before the login prompt), I was able to print from keyboard, > symbols appeared at the screen, however system did not do anything > except this. There were no errors in the logs (console.log, > messages) > > > rm -rf /usr/src/sys//compile/GENERIC > > cd /usr/src/sys//conf > > config GENERIC > > cd ../compile/GENERIC > > make depend > > make > > make install > > > > Once that is done, you can just repeat: > > > > cd /usr/src/sys//compile/GENERIC > > make > > make install > > > > if only one or two files are changed. It is not always safe but > > it usually works. > > Many-many thanks :-)! > > Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 13 18:24:08 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82BF16A41A for ; Thu, 13 Sep 2007 18:24:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB5513C442 for ; Thu, 13 Sep 2007 18:24:08 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8DIO7dG013409; Thu, 13 Sep 2007 14:24:07 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Thu, 13 Sep 2007 14:23:58 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <325305250709131059g6b73cf51o9dc9e09d7e0c2800@mail.gmail.com> <200709131416.21302.jkim@FreeBSD.org> In-Reply-To: <200709131416.21302.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709131424.05193.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4264/Thu Sep 13 02:06:05 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 18:24:09 -0000 [Sorry for the previous empty reply.] On Thursday 13 September 2007 02:16 pm, Jung-uk Kim wrote: > On Thursday 13 September 2007 01:59 pm, Denis wrote: > > On 9/13/07, Jung-uk Kim wrote: > > > Please remove spinlock_enter() and spinlock_exit() from > > > OsdSynch.c and retry. > > > > So I applied your patch, Nate's patch, removed spinlock_enter() > > and spinlock_exit() from OsdSynch.c and tried to to play a little > > with booting with ACPI: > > For the first time I could boot with ACPI and login to the > > system. But after several minutes I was unable to enter any > > symbol from the keyboard, however was able to switch between > > consoles (alt+Fx). > > > > Couple times got kernel panic: > > --- > > panic: _sx_xlock_hard: recursed on non recursive sx ACPI embedded > > controller @ > > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:209 > > > > cpuid = 0 > > KDB: enter: panic > > [thread: pid 8 tid 100018 ] > > Stopped at kbd_enter+0x32: leave > > db> > > --- Actually I am seeing the same problem. Nate, sx lock is recursing during AcpiInstallAddressSpaceHandler() -> EcSpaceHandler(). Can you take a look at it? > > and couple time booting process stops at the different stages > > (but before the login prompt), I was able to print from keyboard, > > symbols appeared at the screen, however system did not do > > anything except this. There were no errors in the logs > > (console.log, messages) Thanks for the feedback, Jung-uk Kim > > > rm -rf /usr/src/sys//compile/GENERIC > > > cd /usr/src/sys//conf > > > config GENERIC > > > cd ../compile/GENERIC > > > make depend > > > make > > > make install > > > > > > Once that is done, you can just repeat: > > > > > > cd /usr/src/sys//compile/GENERIC > > > make > > > make install > > > > > > if only one or two files are changed. It is not always safe > > > but it usually works. > > > > Many-many thanks :-)! > > > > Best regards, Denis. From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 11:26:47 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E47F16A41A for ; Fri, 14 Sep 2007 11:26:47 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id E7D5E13C45E for ; Fri, 14 Sep 2007 11:26:46 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so611747rvb for ; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=J/lLhZtaOchrNeMbXNGFpEJMnEbimpElGUsHXaD4Rnw=; b=Q5RIjaqGQ9mRkt7OENA91XQm/aKqgdkOn5HFiqraAdEgoRM6lNrXlVULo/G9pK3/793QATlTUun/ktWazbC1na/uWo6ARIq6za07ar7ngpjTVbrs4Uvb3/ZmJSNV84h2C21xMr6XKNH4YVLn6BckTWmQ0BE7CTSYi/34pf+9uGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VPampRX7wRbQp1YDMeKAV9ESkqFN1EZQzW8nEMwRVAjtfB/h7Ka9d8RVTS1SoW/EU1lz1iyZzNoEtqVEf+EtzaePkAuUhLcqakJ72iRlRFLCVe5y1RcSRbEyZVxsBre5PX77/gDiYZmPPmNoVOTU3hTqhPw+zfJMmOpbT1JfBSg= Received: by 10.114.198.1 with SMTP id v1mr1682182waf.1189769206330; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Fri, 14 Sep 2007 04:26:46 -0700 (PDT) Message-ID: <632825b40709140426s466e20afkc410c56aa4f1dae9@mail.gmail.com> Date: Fri, 14 Sep 2007 08:26:46 -0300 From: William To: "Nate Lawson" In-Reply-To: <46E6DF34.1060304@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> <46E6DF34.1060304@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 11:26:47 -0000 On 9/11/07, Nate Lawson wrote: > > William Grzybowski wrote: > > On 9/6/07, *Nate Lawson* > wrote: > > > > Nate Lawson wrote: > > > I've done some major rework on the EC driver. This should help > with > > > various problems, including timeouts while checking battery status > or > > > temperature. The attached patches are for 6.x and 7.x. Please > > test and > > > let me know if you get any new errors on dmesg or if it fixes > > things for > > > you (especially HP/Compaq laptop owners). > > > > > > If you still have problems, try setting each of these tunables > > > individually and then both together (i.e., in > > /boot/loader.conf). Note > > > that this will be four (4) test runs total, so don't just set both > and > > > say it doesn't work. > > > > > > debug.acpi.ec.burst= "1" > > > debug.acpi.ec.polled="1" > > > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, > no > > > problems in either regular or burst mode. > > > > > > > > > Commit message: > > > Rewrite the EC driver event model. The main goal is to avoid > > > polling/interrupt-driven fallback and instead use polling only > during > > > boot and pure interrupt-driven mode after boot. Polled mode could > be > > > relegated completely to a legacy role if we could enable > interrupts > > > during boot. Polled mode can be forced after boot by setting > > > debug.acpi.ec.polled="1", i.e. if there are timeouts. > > > > One minor note -- power off shutdown (shutdown/halt -p) is turned > into a > > (safe) reboot with this patch. I have tested the fix, which is just > to > > force polled mode during shutdown as well. I don't have time to > > re-roll > > the patch today but will send tomorrow. > > > > Please test the patch as posted, ignoring that minor issue. The > test > > results during normal use are still valid. > > > > > > Hi Nate, > > > > I tested this patch on my acer notebook (intel chipset) and i did not > > notice any changes, unless some errors on dmesg, like: > > acpi_ec0: EcCommand: no response to 0x84 > > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > > acpi_ec0: EcCommand: no response to 0x82 > > acpi_ec0: EcCommand: no response to 0x80 > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > > ACPI Error (psparse-0626): Method parse/execution failed > > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE > > As I noted before, your system enters the poll loop with the status > appearing to be already complete. Can you get back to me on my previous > questions, especially whether forcing polled mode works for you? I > didn't see any errors in that dmesg case. > > I've updated the patches to do one final check if the interrupt-driven > mode gets a timeout. If the status is complete, it will force the > system back into polled mode since interrupt mode doesn't work. It also > has a case for polled mode during boot where the status appears to be > already complete. It waits a short while before actually checking the > status, just in case the EC is really slow and hasn't gotten to work on > the new request yet. > > Give it a try also, with no tunables set. Nate, Yesterday I send to you privately the answers which you asked for, annoy me if you didn't receive... Today I recompiled the kernel from a today's cvs without modules with KTR and recompiled the acpi module without any patches, without any debug option on boot, the system can initialize the battery and the thermal, when i enable any debug (polled or burst or even both) the battery get ready after 2 tries. Tonight I will remake some testes with your patches to make sure about things which I told you. Thanks, -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 14:03:53 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BF716A418; Fri, 14 Sep 2007 14:03:53 +0000 (UTC) (envelope-from kevin.foo@zaidibrahim.com) Received: from tba.zaidibrahim.com (tba.zaidibrahim.com [202.75.165.180]) by mx1.freebsd.org (Postfix) with ESMTP id 391D113C457; Fri, 14 Sep 2007 14:03:52 +0000 (UTC) (envelope-from kevin.foo@zaidibrahim.com) thread-index: Acf21lyWks4UoLF1TEiKYH/4gj5viQ== X-MessageTextProcessor: DisclaimIt (2.60.261) [Zaid Ibrahim & Co., Kuala Lumpur, Malaysia] Received: from mzimyklex02.zaidibrahim.com ([10.209.33.203]) by tba.zaidibrahim.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 21:51:33 +0800 Received: from b3ta.zaidibrahim.com ([10.209.46.120]) by mzimyklex02.zaidibrahim.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 21:51:33 +0800 From: "Kevin Foo" Organization: Zaid Ibrahim & Co. To: Date: Fri, 14 Sep 2007 21:55:56 +0800 User-Agent: - References: <46E0777A.8070901@root.org> In-Reply-To: <46E0777A.8070901@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Class: urn:content-classes:message Importance: normal Priority: normal Message-ID: <200709142155.56887.kevin.foo@zaidibrahim.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4073 X-OriginalArrivalTime: 14 Sep 2007 13:51:33.0295 (UTC) FILETIME=[5C28A3F0:01C7F6D6] Cc: acpi@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 14:03:54 -0000 Hi Nate, I have tested the patch, ecng-6c.diff, on Compaq Presario V3417AU laptop = and ran all 4 tests. Here are the outputs: Test 1 : no tunables set http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT.txt Error : NONE working properly Test 2 : debug.acpi.ec.burst=3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-ec.burst-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-ec.burst-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca20), AE_NO_HARDWARE_RESPONSE acpi_ec0: can't install address space handler for \\_SB_.PCI0.EC0_ - = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca20), AE_NO_HARDWARE_RESPONSE device_attach: acpi_ec0 attach returned 6 battery0: battery initialization start ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0acpi_acad0: acline initialization start _.GBST] (Node 0xc88c7020), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c6d00), AE_NOT_EXIST battery0: error fetching current battery status -- AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c7040), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c6d20), AE_NOT_EXIST battery0: error fetching current battery info -- AE_NOT_EXIST Test 3 : debug.acpi.ec.polled=3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-ec.polled-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-ec.polled-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 battery0: battery initialization start acpi_acad0: acline initialization start acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBST] (Node 0xc88c7020), AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c6d00), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery status -- = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c7040), AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c6d20), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery info -- AE_NO_HARDWARE_RESPONSE Test 4 : both =3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-both-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-both-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca40), AE_NO_HARDWARE_RESPONSE acpi_ec0: can't install address space handler for \\_SB_.PCI0.EC0_ - = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca40), AE_NO_HARDWARE_RESPONSE device_attach: acpi_ec0 attach returned 6 battery0: battery initialization start ACPI-0356: *** Error: Region EmbeddedControl(3)acpi_acad0: acline = initialization start has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBST] (Node 0xc88c8040), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c7d20), AE_NOT_EXIST battery0: error fetching current battery status -- AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c8060), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c7d40), AE_NOT_EXIST battery0: error fetching current battery info -- AE_NOT_EXIST I also uploaded acpidump for the said unit at = http://bsd.ipv6.la/v3417au/compaq-presario-V3417AU.asl for your perusal. Please let me know if you need further tests on Compaq Presario V3417AU. = Thanks for the work. --=20 Warm regards, Kevin Foo Key fingerprint : 4B23 FC1C E50B 9693 CCDD 2A7D A048 E909 8924 9BDD Public key : = http://keyserver.linux.it/pks/lookup?op=3Dget&search=3D0x89249BDD On Friday 07 September 2007, Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test = and > let me know if you get any new errors on dmesg or if it fixes things = for > you (especially HP/Compaq laptop owners). >=20 > If you still have problems, try setting each of these tunables > individually and then both together (i.e., in /boot/loader.conf). = Note > that this will be four (4) test runs total, so don't just set both and > say it doesn't work. >=20 > debug.acpi.ec.burst=3D"1" > debug.acpi.ec.polled=3D"1" >=20 > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > problems in either regular or burst mode. >=20 >=20 > Commit message: > Rewrite the EC driver event model. The main goal is to avoid > polling/interrupt-driven fallback and instead use polling only during > boot and pure interrupt-driven mode after boot. Polled mode could be > relegated completely to a legacy role if we could enable interrupts > during boot. Polled mode can be forced after boot by setting > debug.acpi.ec.polled=3D"1", i.e. if there are timeouts. >=20 > - Use polling only during boot or if requested by the user. = Otherwise, > use a generation count of GPEs, incremented atomically. This prevents > an old status value from being used if the EC is really slow and the > same condition (i.e. multiple IBEs for a write transaction) is being > checked. > - Check for and run the query handler directly if the SCI bit is set = in > the status register during boot. Previously, the query handler = wouldn't > run until interrupts were finally enabled late in boot. > - During boot and after starting a command, check if the event appears > to already have occurred before we even start waiting. If so, it's > possible the EC is very slow and we might accept an old status value. > Print a warning in this case. Once we've booted, interrupt-driven = mode > should work just fine but polled mode will be unreliable. There's not > much more we can do about this until interrupts are enabled during = boot. > - Hold the sx lock over the entire query handler, since the GPE = handler > no longer grabs any lock > - Use upper-case hex for the _Qxx method > - Use device_printf for errors, don't hide them under verbose > - Increase default total timeout to 750 ms and polling interval to 5 = us. > - Don't pass the status value via the softc. Just read it directly. > - Remove the mutex. We use the sx lock for transaction serialization > with the query handler. > - Remove the Intel copyright notice as no code of theirs was ever > present in this file (verified against rev 1.1) >=20 >=20 > -Nate >=20 *****************************Internet Email Confidentiality Footer = *****************************=20 Legal Privilege & Confidentiality=20 -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------- This email contains privileged and/or confidential information. If you = are not the intended recipient (or responsible for delivery of the = message to such person) or if you have inadvertently received this = email, you should destroy or delete this message and notify the sender = by reply email accordingly. If you or your employer do not consent to = using Internet email for messages of this kind please advise immediately = by sending an email to the sender of this message . All opinions, = conclusions and other information in this message that do not relate to = the official business of Zaid Ibrahim & Co shall be understood as = neither given nor endorsed by Zaid Ibrahim & Co. Our company accepts no = liability for the content of this email, or for the consequences of any = actions taken on the basis of the information provided, unless that = information is subsequently confirmed in writing. =20 Caveat=20 -------------------------------------------------------------------------= -------------------------------------------------------------------------= -----------WARNING: Computer viruses can be transmitted via email, and = you should check this email and any attachments for the presence of = viruses. Zaid Ibrahim & Co accepts no liability for any damage caused by = any virus transmitted by this email. Our employees are expressly = required not to make defamatory statements nor infringe or authorise any = infringement of copyright or any other legal right via any = communications. Any such communication is contrary to our company policy = and outside the scope of the employment of said individual. We will not = be liable for such communication.=20 From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 14:03:53 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BF716A418; Fri, 14 Sep 2007 14:03:53 +0000 (UTC) (envelope-from kevin.foo@zaidibrahim.com) Received: from tba.zaidibrahim.com (tba.zaidibrahim.com [202.75.165.180]) by mx1.freebsd.org (Postfix) with ESMTP id 391D113C457; Fri, 14 Sep 2007 14:03:52 +0000 (UTC) (envelope-from kevin.foo@zaidibrahim.com) thread-index: Acf21lyWks4UoLF1TEiKYH/4gj5viQ== X-MessageTextProcessor: DisclaimIt (2.60.261) [Zaid Ibrahim & Co., Kuala Lumpur, Malaysia] Received: from mzimyklex02.zaidibrahim.com ([10.209.33.203]) by tba.zaidibrahim.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 21:51:33 +0800 Received: from b3ta.zaidibrahim.com ([10.209.46.120]) by mzimyklex02.zaidibrahim.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Sep 2007 21:51:33 +0800 From: "Kevin Foo" Organization: Zaid Ibrahim & Co. To: Date: Fri, 14 Sep 2007 21:55:56 +0800 User-Agent: - References: <46E0777A.8070901@root.org> In-Reply-To: <46E0777A.8070901@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Class: urn:content-classes:message Importance: normal Priority: normal Message-ID: <200709142155.56887.kevin.foo@zaidibrahim.com> x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.4073 X-OriginalArrivalTime: 14 Sep 2007 13:51:33.0295 (UTC) FILETIME=[5C28A3F0:01C7F6D6] Cc: acpi@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 14:03:54 -0000 Hi Nate, I have tested the patch, ecng-6c.diff, on Compaq Presario V3417AU laptop = and ran all 4 tests. Here are the outputs: Test 1 : no tunables set http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT.txt Error : NONE working properly Test 2 : debug.acpi.ec.burst=3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-ec.burst-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-ec.burst-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca20), AE_NO_HARDWARE_RESPONSE acpi_ec0: can't install address space handler for \\_SB_.PCI0.EC0_ - = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca20), AE_NO_HARDWARE_RESPONSE device_attach: acpi_ec0 attach returned 6 battery0: battery initialization start ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0acpi_acad0: acline initialization start _.GBST] (Node 0xc88c7020), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c6d00), AE_NOT_EXIST battery0: error fetching current battery status -- AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c7040), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c6d20), AE_NOT_EXIST battery0: error fetching current battery info -- AE_NOT_EXIST Test 3 : debug.acpi.ec.polled=3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-ec.polled-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-ec.polled-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 battery0: battery initialization start acpi_acad0: acline initialization start acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBST] (Node 0xc88c7020), AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c6d00), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery status -- = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c7040), AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c6d20), AE_NO_HARDWARE_RESPONSE battery0: error fetching current battery info -- AE_NO_HARDWARE_RESPONSE Test 4 : both =3D"1" http://bsd.ipv6.la/v3417au/dmesg-V3417AU-BATT-both-1.txt http://bsd.ipv6.la/v3417au/sysctl-V3417AU-BATT-both-1.txt Error : acpi_ec0: port 0x62,0x66 on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca40), AE_NO_HARDWARE_RESPONSE acpi_ec0: can't install address space handler for \\_SB_.PCI0.EC0_ - = AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI-0501: *** Error: Handler for [EmbeddedControl] returned = AE_NO_HARDWARE_RESPONSE ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_._REG] (Node 0xc887ca40), AE_NO_HARDWARE_RESPONSE device_attach: acpi_ec0 attach returned 6 battery0: battery initialization start ACPI-0356: *** Error: Region EmbeddedControl(3)acpi_acad0: acline = initialization start has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBST] (Node 0xc88c8040), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BST] (Node 0xc88c7d20), AE_NOT_EXIST battery0: error fetching current battery status -- AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.GBIF] (Node 0xc88c8060), AE_NOT_EXIST ACPI-1304: *** Error: Method execution failed = [\\_SB_.PCI0.EC0_.BAT0._BIF] (Node 0xc88c7d40), AE_NOT_EXIST battery0: error fetching current battery info -- AE_NOT_EXIST I also uploaded acpidump for the said unit at = http://bsd.ipv6.la/v3417au/compaq-presario-V3417AU.asl for your perusal. Please let me know if you need further tests on Compaq Presario V3417AU. = Thanks for the work. --=20 Warm regards, Kevin Foo Key fingerprint : 4B23 FC1C E50B 9693 CCDD 2A7D A048 E909 8924 9BDD Public key : = http://keyserver.linux.it/pks/lookup?op=3Dget&search=3D0x89249BDD On Friday 07 September 2007, Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test = and > let me know if you get any new errors on dmesg or if it fixes things = for > you (especially HP/Compaq laptop owners). >=20 > If you still have problems, try setting each of these tunables > individually and then both together (i.e., in /boot/loader.conf). = Note > that this will be four (4) test runs total, so don't just set both and > say it doesn't work. >=20 > debug.acpi.ec.burst=3D"1" > debug.acpi.ec.polled=3D"1" >=20 > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > problems in either regular or burst mode. >=20 >=20 > Commit message: > Rewrite the EC driver event model. The main goal is to avoid > polling/interrupt-driven fallback and instead use polling only during > boot and pure interrupt-driven mode after boot. Polled mode could be > relegated completely to a legacy role if we could enable interrupts > during boot. Polled mode can be forced after boot by setting > debug.acpi.ec.polled=3D"1", i.e. if there are timeouts. >=20 > - Use polling only during boot or if requested by the user. = Otherwise, > use a generation count of GPEs, incremented atomically. This prevents > an old status value from being used if the EC is really slow and the > same condition (i.e. multiple IBEs for a write transaction) is being > checked. > - Check for and run the query handler directly if the SCI bit is set = in > the status register during boot. Previously, the query handler = wouldn't > run until interrupts were finally enabled late in boot. > - During boot and after starting a command, check if the event appears > to already have occurred before we even start waiting. If so, it's > possible the EC is very slow and we might accept an old status value. > Print a warning in this case. Once we've booted, interrupt-driven = mode > should work just fine but polled mode will be unreliable. There's not > much more we can do about this until interrupts are enabled during = boot. > - Hold the sx lock over the entire query handler, since the GPE = handler > no longer grabs any lock > - Use upper-case hex for the _Qxx method > - Use device_printf for errors, don't hide them under verbose > - Increase default total timeout to 750 ms and polling interval to 5 = us. > - Don't pass the status value via the softc. Just read it directly. > - Remove the mutex. We use the sx lock for transaction serialization > with the query handler. > - Remove the Intel copyright notice as no code of theirs was ever > present in this file (verified against rev 1.1) >=20 >=20 > -Nate >=20 *****************************Internet Email Confidentiality Footer = *****************************=20 Legal Privilege & Confidentiality=20 -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------- This email contains privileged and/or confidential information. If you = are not the intended recipient (or responsible for delivery of the = message to such person) or if you have inadvertently received this = email, you should destroy or delete this message and notify the sender = by reply email accordingly. If you or your employer do not consent to = using Internet email for messages of this kind please advise immediately = by sending an email to the sender of this message . All opinions, = conclusions and other information in this message that do not relate to = the official business of Zaid Ibrahim & Co shall be understood as = neither given nor endorsed by Zaid Ibrahim & Co. Our company accepts no = liability for the content of this email, or for the consequences of any = actions taken on the basis of the information provided, unless that = information is subsequently confirmed in writing. =20 Caveat=20 -------------------------------------------------------------------------= -------------------------------------------------------------------------= -----------WARNING: Computer viruses can be transmitted via email, and = you should check this email and any attachments for the presence of = viruses. Zaid Ibrahim & Co accepts no liability for any damage caused by = any virus transmitted by this email. Our employees are expressly = required not to make defamatory statements nor infringe or authorise any = infringement of copyright or any other legal right via any = communications. Any such communication is contrary to our company policy = and outside the scope of the employment of said individual. We will not = be liable for such communication.=20 From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 17:12:37 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34EFF16A419; Fri, 14 Sep 2007 17:12:37 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id F10B413C45D; Fri, 14 Sep 2007 17:12:36 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.3.58]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JOD00G5XACZ0F80@mta-1.ms.rz.RWTH-Aachen.de>; Fri, 14 Sep 2007 18:41:23 +0200 (CEST) Received: from talos.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.3.22]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 14 Sep 2007 18:41:23 +0200 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8/8.13.8/1) with ESMTP id l8EGfNoJ030405; Fri, 14 Sep 2007 18:41:23 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IWEEN-00027k-1m; Fri, 14 Sep 2007 18:41:23 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id B47D33F41B; Fri, 14 Sep 2007 18:41:17 +0200 (CEST) Date: Fri, 14 Sep 2007 18:41:17 +0200 From: Christian Brueffer In-reply-to: <46E0777A.8070901@root.org> To: Nate Lawson Message-id: <20070914164117.GC1872@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=raC6veAxrt5nqIoY Content-disposition: inline X-IronPort-AV: E=Sophos;i="4.20,256,1186351200"; d="scan'208";a="22613638" X-Operating-System: FreeBSD 6.2-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <46E0777A.8070901@root.org> User-Agent: Mutt/1.5.11 Cc: acpi@FreeBSD.ORG, current@FreeBSD.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 17:12:37 -0000 --raC6veAxrt5nqIoY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 06, 2007 at 02:56:10PM -0700, Nate Lawson wrote: > I've done some major rework on the EC driver. This should help with > various problems, including timeouts while checking battery status or > temperature. The attached patches are for 6.x and 7.x. Please test and > let me know if you get any new errors on dmesg or if it fixes things for > you (especially HP/Compaq laptop owners). >=20 Tested version c on a Thinkpad T41p, everything worked before, everything works now. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --raC6veAxrt5nqIoY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFG6rmtbHYXjKDtmC0RAuuVAJ0YJjtQzElsB/h1FvR7ExESxqzmrQCg7TcJ E81UtFga8jtRYSi4eJWdM/s= =g2PP -----END PGP SIGNATURE----- --raC6veAxrt5nqIoY-- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 18:42:15 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A96016A46E; Fri, 14 Sep 2007 18:42:15 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id CFF7913C48A; Fri, 14 Sep 2007 18:42:13 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A54F1D.dip.t-dialin.net [84.165.79.29]) by redbull.bpaserver.net (Postfix) with ESMTP id 7E3A52E05C; Fri, 14 Sep 2007 20:23:30 +0200 (CEST) Received: from deskjail (deskjail.Leidinger.net [192.168.1.109]) by outgoing.leidinger.net (Postfix) with ESMTP id 476D65B4812; Fri, 14 Sep 2007 20:23:04 +0200 (CEST) Date: Fri, 14 Sep 2007 20:22:19 +0200 From: Alexander Leidinger To: "Constantine A. Murenin" Message-ID: <20070914202219.3fb5f583@deskjail> In-Reply-To: <46E3E592.6000704@FreeBSD.org> References: <20070908125004.6362fefe@deskjail> <46E2AC7F.70202@FreeBSD.org> <20070908174205.7e8c460a@deskjail> <46E2C96B.3080409@FreeBSD.org> <20070908205656.054b5a70@deskjail> <46E30EAC.8090407@FreeBSD.org> <20070909130612.26ec17dc@deskjail> <46E3E592.6000704@FreeBSD.org> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i686-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.8, required 8, BAYES_00 -15.00, J_CHICKENPOX_74 0.60, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: acpi@freebsd.org, njl@freebsd.org Subject: Re: I'm going to try the sensors patch "soon" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 18:42:15 -0000 Quoting "Constantine A. Murenin" (Sun, 09 Sep 2007 08:22:42 -0400): > >>So did lm0 not attach at all? All of the above Winbond Super I/O > >>Hardware Monitors should be supported by lm(4). > >> > >>This is what I have in my freebsd.dale dmesg: > >> > >>lm0: at port 0x290-0x297 on isa0 > > > > > > Hmmm... I will try later after a reboot. > > Cool, thanks -- I really hope it works! ;) Nope. But I get the ACPI error message other people reported. I didn't try if I get lm working without ACPI, as the other one which reported success without ACPI did. acpi@ (I hope this is the right ML, as I can't access www.freebsd.org ATM) and njl@ CCed. The ACPI message is: ---snip--- acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed ---snip--- Acpi/njl, can you shed some light on what might be wrong? Do you need something else (asl or whatever)? Bye, Alexander. -- Why don't you ever enter and CONTESTS, Marvin?? Don't you know your own ZIPCODE? http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 20:28:29 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B8816A417 for ; Fri, 14 Sep 2007 20:28:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 52E6313C45E for ; Fri, 14 Sep 2007 20:28:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8EKSR6o096764; Fri, 14 Sep 2007 16:28:28 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Fri, 14 Sep 2007 16:28:16 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709131416.21302.jkim@FreeBSD.org> <200709131424.05193.jkim@FreeBSD.org> In-Reply-To: <200709131424.05193.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_o7u6GTVSH0Q6l+C" Message-Id: <200709141628.24801.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4272/Fri Sep 14 04:36:36 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 20:28:29 -0000 --Boundary-00=_o7u6GTVSH0Q6l+C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 13 September 2007 02:23 pm, Jung-uk Kim wrote: > [Sorry for the previous empty reply.] > > On Thursday 13 September 2007 02:16 pm, Jung-uk Kim wrote: > > On Thursday 13 September 2007 01:59 pm, Denis wrote: > > > On 9/13/07, Jung-uk Kim wrote: > > > > Please remove spinlock_enter() and spinlock_exit() from > > > > OsdSynch.c and retry. > > > > > > So I applied your patch, Nate's patch, removed spinlock_enter() > > > and spinlock_exit() from OsdSynch.c and tried to to play a > > > little with booting with ACPI: > > > For the first time I could boot with ACPI and login to the > > > system. But after several minutes I was unable to enter any > > > symbol from the keyboard, however was able to switch between > > > consoles (alt+Fx). > > > > > > Couple times got kernel panic: > > > --- > > > panic: _sx_xlock_hard: recursed on non recursive sx ACPI > > > embedded controller @ > > > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:209 > > > > > > cpuid = 0 > > > KDB: enter: panic > > > [thread: pid 8 tid 100018 ] > > > Stopped at kbd_enter+0x32: leave > > > db> > > > --- > > Actually I am seeing the same problem. Can you try this patch *after* applying Nate's patch? It should fix this problem. Thanks, Jung-uk Kim --Boundary-00=_o7u6GTVSH0Q6l+C Content-Type: text/plain; charset="iso-8859-1"; name="acpi_ec.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="acpi_ec.diff" --- src/sys/dev/acpica/acpi_ec.c.orig 2007-09-14 16:20:20.000000000 -0400 +++ src/sys/dev/acpica/acpi_ec.c 2007-09-14 16:08:04.000000000 -0400 @@ -624,6 +624,7 @@ } /* Evaluate _Qxx to respond to the controller. */ + EcUnlock(sc); snprintf(qxx, sizeof(qxx), "_Q%02X", Data); AcpiUtStrupr(qxx); Status = AcpiEvaluateObject(sc->ec_handle, qxx, NULL, NULL); @@ -631,8 +632,6 @@ device_printf(sc->ec_dev, "evaluation of query method %s failed: %s\n", qxx, AcpiFormatException(Status)); } - - EcUnlock(sc); } /* --Boundary-00=_o7u6GTVSH0Q6l+C-- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 21:54:44 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A91B16A419 for ; Fri, 14 Sep 2007 21:54:44 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn2.hy.skanova.net (pne-smtpout3-sn2.hy.skanova.net [81.228.8.111]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB2D13C480 for ; Fri, 14 Sep 2007 21:54:43 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from hoasb-ff0cdd00-61.dhcp.inet.fi (80.221.12.61) by pne-smtpout3-sn2.hy.skanova.net (7.2.075) id 46E521E000044AD5; Fri, 14 Sep 2007 22:44:53 +0200 From: Mikael Ikivesi To: Nate Lawson Date: Fri, 14 Sep 2007 23:44:50 +0300 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <46E0777A.8070901@root.org> <200709081054.14073.mikael.ikivesi@pp.inet.fi> <46E894DC.6020707@root.org> In-Reply-To: <46E894DC.6020707@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709142344.52584.mikael.ikivesi@pp.inet.fi> Cc: freebsd-acpi@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 21:54:44 -0000 Oh....sorry, but I met next panic attack :( After updating src-all, re-patching and recompiling I am left with acpi errors during boot and panic. I tried all patches you send (ecng7a/b/c). battery0: on acpi0 acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00011610a0), AE_NO_HARDWARE_RESPONSE ACPI Error (uteval-0309): Method execution failed [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00011610a0), AE_NO_HARDWARE_RESPONSE acpi_acad0: on acpi0 AND if I unplug the power cable system panics. Piece from core dump: panic: _sx_xlock_hard: recursed on non-recursive sx ACPI embedded controller @ /usr/src/sys/dev/acpica/acpi_ec.c:209 KDB: enter: panic panic: from debugger Uptime: 5m55s Physical memory: 884 MB Dumping 56 MB: System also panics if I try to boot without power cable plugged.. -Mikael From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 14 21:58:24 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F153A16A418 for ; Fri, 14 Sep 2007 21:58:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id B050513C45A for ; Fri, 14 Sep 2007 21:58:24 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8ELwNU6002708; Fri, 14 Sep 2007 17:58:23 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Fri, 14 Sep 2007 17:58:16 -0400 User-Agent: KMail/1.6.2 References: <46E0777A.8070901@root.org> <46E894DC.6020707@root.org> <200709142344.52584.mikael.ikivesi@pp.inet.fi> In-Reply-To: <200709142344.52584.mikael.ikivesi@pp.inet.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709141758.20649.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4272/Fri Sep 14 04:36:36 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Subject: Re: PATCH: ecng for 6.x and 7.x X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 21:58:25 -0000 On Friday 14 September 2007 04:44 pm, Mikael Ikivesi wrote: > Oh....sorry, but I met next panic attack :( > > > After updating src-all, re-patching and recompiling I am left with > acpi errors during boot and panic. I tried all patches you send > (ecng7a/b/c). > > > battery0: on acpi0 > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned > by Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00011610a0), > AE_NO_HARDWARE_RESPONSE > ACPI Error (uteval-0309): Method execution failed > [\_SB_.PCI0.LPC0.EC0_.BAT0._STA] (Node 0xffffff00011610a0), > AE_NO_HARDWARE_RESPONSE > acpi_acad0: on acpi0 > > > > > AND if I unplug the power cable system panics. > Piece from core dump: > > panic: _sx_xlock_hard: recursed on non-recursive sx ACPI embedded > controller @ /usr/src/sys/dev/acpica/acpi_ec.c:209 > > KDB: enter: panic > panic: from debugger > Uptime: 5m55s > Physical memory: 884 MB > Dumping 56 MB: > > > > System also panics if I try to boot without power cable plugged.. I just posted a patch to fix this problem: http://docs.freebsd.org/cgi/mid.cgi?200709141628.24801.jkim Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 15 09:04:55 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA8616A418 for ; Sat, 15 Sep 2007 09:04:55 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7F86D13C458 for ; Sat, 15 Sep 2007 09:04:55 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1154420fka for ; Sat, 15 Sep 2007 02:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ua027v0RRNyqn/EQQz67FfO+C5hxXIssYPSy2E+RVic=; b=efu3kZmRE30r55IHp1dYg5JjRujyCqU1jHVdvj4HfzVUfMsvVraZoz0v7/ZtQkzycBmogg4anLTwiC0bhBTGjTHt1V8ujgnPmEdrfhTRU3ZqkhoA3u2Odv6grsiDGjxo3VmEIgVxhG2ageS/dLS1ztrELo/m4B9ePWZVJq16sow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XUM20TPZgu5JWEiw0XN5ylrIJiKrwM5d1thP41VxXV4nfh9tvgbD/34eCsCFmhc1PHy6n5j4RJ5y/yNPasMPbk031PFZXxAh4pytIaziF9EFBRSPzuoxhJa2O1oROHuRtJQxyLxvQHwnxgRLHjHLiNhZ5ZkldFCUsaKHwnOM14M= Received: by 10.86.62.3 with SMTP id k3mr2043305fga.1189847093891; Sat, 15 Sep 2007 02:04:53 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Sat, 15 Sep 2007 02:04:53 -0700 (PDT) Message-ID: <325305250709150204i311c658bwfa187cd0684771f@mail.gmail.com> Date: Sat, 15 Sep 2007 13:04:53 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709141628.24801.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709131416.21302.jkim@FreeBSD.org> <200709131424.05193.jkim@FreeBSD.org> <200709141628.24801.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 09:04:56 -0000 On 9/15/07, Jung-uk Kim wrote: > > > > panic: _sx_xlock_hard: recursed on non recursive sx ACPI > > > > embedded controller @ > > > > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:209 > > > > > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread: pid 8 tid 100018 ] > > > > Stopped at kbd_enter+0x32: leave > > > > db> > > > > --- > > > > Actually I am seeing the same problem. > > Can you try this patch *after* applying Nate's patch? It should fix > this problem. I applied Nate's patch, your patch and this patch and got kernel panic: --- panic: blockable sleep lock (sleep mutex) 32 @ vm/uma_core:1830 cpuid = 0 KDB: enter: panic [thread pid 21 tid 100013 ] Stopped at kdb_enter+0x32: leave --- Best regards, Denis From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 15 13:11:48 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9154916A417 for ; Sat, 15 Sep 2007 13:11:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 602AA13C46A for ; Sat, 15 Sep 2007 13:11:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l8FDBkm1028603; Sat, 15 Sep 2007 09:11:46 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Denis Date: Sat, 15 Sep 2007 09:11:36 -0400 User-Agent: KMail/1.6.2 References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709141628.24801.jkim@FreeBSD.org> <325305250709150204i311c658bwfa187cd0684771f@mail.gmail.com> In-Reply-To: <325305250709150204i311c658bwfa187cd0684771f@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200709150911.42648.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/4279/Sat Sep 15 08:53:34 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-acpi@FreeBSD.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 13:11:48 -0000 On Saturday 15 September 2007 05:04 am, Denis wrote: > On 9/15/07, Jung-uk Kim wrote: > > > > > panic: _sx_xlock_hard: recursed on non recursive sx ACPI > > > > > embedded controller @ > > > > > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:20 > > > > >9 > > > > > > > > > > cpuid = 0 > > > > > KDB: enter: panic > > > > > [thread: pid 8 tid 100018 ] > > > > > Stopped at kbd_enter+0x32: leave > > > > > db> > > > > > --- > > > > > > Actually I am seeing the same problem. > > > > Can you try this patch *after* applying Nate's patch? It should > > fix this problem. > > I applied Nate's patch, your patch and this patch and got kernel > panic: --- > panic: blockable sleep lock (sleep mutex) 32 @ vm/uma_core:1830 > cpuid = 0 > KDB: enter: panic > [thread pid 21 tid 100013 ] > Stopped at kdb_enter+0x32: leave > --- Did you remove spinlock_enter() and spinlock_exit()? Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 15 15:13:22 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D568116A420 for ; Sat, 15 Sep 2007 15:13:22 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by mx1.freebsd.org (Postfix) with ESMTP id 7399D13C46E for ; Sat, 15 Sep 2007 15:13:22 +0000 (UTC) (envelope-from piloyder@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so866101nfb for ; Sat, 15 Sep 2007 08:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xUk0UyfW/+74dnEB/hLvsogGGL4/UGR7gIzrMQC2Cmw=; b=BwzSIqREYx1v7iApoQu1utEqgeWr7aa4QOwY0eydD0qA/mxc0EHFSSys3USLAgIjntgFkvIvZBvlkI6h0Fv9FMEdY7zvNcx/ok2KzDZBUER+lU+4Ivz22UmXsyC9L977QTfLBKSnUGkGicxJ9MhPUHHbwonuLeb0Swe8LhzkssU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OYp3Sl/3af2yiV4TYkTHX7FnRJVTXQMdTLJLwtmD0nt/KSH/rKup1dUAcUqU32lAtP6q+ZOmh7nqTOEBs/viC5iRgEXGUo5L7ZB8ovfBT+8D0O5jBVsMVMB8EiFh59dDMpooRPRJR6aOOVoXLWwQEpnU845p9vNNShTUvZsClhQ= Received: by 10.86.93.17 with SMTP id q17mr2190535fgb.1189869185040; Sat, 15 Sep 2007 08:13:05 -0700 (PDT) Received: by 10.86.62.15 with HTTP; Sat, 15 Sep 2007 08:13:04 -0700 (PDT) Message-ID: <325305250709150813k64d6c59fp1ddba0b6459eb694@mail.gmail.com> Date: Sat, 15 Sep 2007 19:13:04 +0400 From: Denis To: "Jung-uk Kim" In-Reply-To: <200709150911.42648.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> <200709141628.24801.jkim@FreeBSD.org> <325305250709150204i311c658bwfa187cd0684771f@mail.gmail.com> <200709150911.42648.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI error on Compaq nc6220, FreeBSD 7.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2007 15:13:22 -0000 On 9/15/07, Jung-uk Kim wrote: > On Saturday 15 September 2007 05:04 am, Denis wrote: > > On 9/15/07, Jung-uk Kim wrote: > > > > > > panic: _sx_xlock_hard: recursed on non recursive sx ACPI > > > > > > embedded controller @ > > > > > > /usr/src/sys/modules/acpi/acpi/../../../acpica/acpi_ec.c:20 > > > > > >9 > > > > > > > > > > > > cpuid = 0 > > > > > > KDB: enter: panic > > > > > > [thread: pid 8 tid 100018 ] > > > > > > Stopped at kbd_enter+0x32: leave > > > > > > db> > > > > > > --- > > > > > > > > Actually I am seeing the same problem. > > > > > > Can you try this patch *after* applying Nate's patch? It should > > > fix this problem. > > > > I applied Nate's patch, your patch and this patch and got kernel > > panic: --- > > panic: blockable sleep lock (sleep mutex) 32 @ vm/uma_core:1830 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 21 tid 100013 ] > > Stopped at kdb_enter+0x32: leave > > --- > > Did you remove spinlock_enter() and spinlock_exit()? Sorry, forgot about it. After removing spinlock_enter() and spinlock_exit() I was able to boot with ACPI, there were no kernel panic. However, system "hangs" after some period of time (up to several minutes) - I able to switch between consoles (alt+Fx) but cannot enter anything from the keyboard. Also able to start debugger with ctrl+alt+esc. And sometimes if I enter to debugger and continue to work (with "c") system starts to work (I mean, able to enter from the keyboard). Best regards, Denis