From owner-freebsd-acpi@FreeBSD.ORG Mon Sep 3 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 344E816A419 for ; Mon, 3 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 06D3513C48D for ; Mon, 3 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 l83B7quD078950 for ; Mon, 3 Sep 2007 11:07:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l83B7p6G078946 for freebsd-acpi@FreeBSD.org; Mon, 3 Sep 2007 11:07:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Sep 2007 11:07:51 GMT Message-Id: <200709031107.l83B7p6G078946@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, 03 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. 13 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 Thu Sep 6 21:56: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 C7C2016A41B for ; Thu, 6 Sep 2007 21:56:19 +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 A949113C45A for ; Thu, 6 Sep 2007 21:56:19 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 65524 invoked from network); 6 Sep 2007 21:56:18 -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; 6 Sep 2007 21:56:18 -0000 Message-ID: <46E0777A.8070901@root.org> Date: Thu, 06 Sep 2007 14:56:10 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------020803020602030709060703" Cc: acpi@FreeBSD.ORG Subject: 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, 06 Sep 2007 21:56:19 -0000 This is a multi-part message in MIME format. --------------020803020602030709060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. - 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) -Nate --------------020803020602030709060703 Content-Type: text/x-patch; name="ecng-6a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-6a.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 6 Sep 2007 21:16:14 -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) { + 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 || 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 || 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); } --------------020803020602030709060703 Content-Type: text/x-patch; name="ecng-7a.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ecng-7a.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 6 Sep 2007 21:22:02 -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) { + 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 || 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 || 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"); } --------------020803020602030709060703-- From owner-freebsd-acpi@FreeBSD.ORG Thu Sep 6 21:59:52 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 C95C216A418 for ; Thu, 6 Sep 2007 21:59:52 +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 95B8213C428 for ; Thu, 6 Sep 2007 21:59:52 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 66396 invoked from network); 6 Sep 2007 21:59:53 -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; 6 Sep 2007 21:59:53 -0000 Message-ID: <46E0784D.6030600@root.org> Date: Thu, 06 Sep 2007 14:59: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> In-Reply-To: <325305250709010712n4bd0d62l9a144572441cf3dc@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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, 06 Sep 2007 21:59:52 -0000 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 Thu Sep 6 22:17: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 7B21016A419 for ; Thu, 6 Sep 2007 22:17:22 +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 47EFC13C46B for ; Thu, 6 Sep 2007 22:17:22 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 68262 invoked from network); 6 Sep 2007 22:17:23 -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; 6 Sep 2007 22:17:23 -0000 Message-ID: <46E07AAF.2060000@root.org> Date: Thu, 06 Sep 2007 15:09:51 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: current@FreeBSD.org References: <46E0777A.8070901@root.org> In-Reply-To: <46E0777A.8070901@root.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 06 Sep 2007 22:17:22 -0000 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. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 03:06: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 AEA3F16A46E for ; Fri, 7 Sep 2007 03:06:33 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 8491713C4A6 for ; Fri, 7 Sep 2007 03:06:33 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so308361rvb for ; Thu, 06 Sep 2007 20:06:33 -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:mime-version:content-type; bh=PyUdIikqshex32CYhqI8VPeCcQFOr9XLrpEN2PzvnUU=; b=lplU6wH1cokM6D4hJhTK63G1slp7ZjMsDKS83pBqfMp8A5ppWCVgUaN+Z8L9LDMmKACD03jAs5oCqUwmK1PkCG2kpqP3h7Dxye8GVYNV3BrmhcpR7twfnGhtPtesUCD/r+TcRU9IuGRZF3omSUeYx9Z37xunAFOrDRX5XP9mG9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GS487BnHJw/FsgrEMY6C1/CaAONlOYSjVb+0trAt9eh65vfE3cDwaMEjDBnXqkhnSYRkCsabAXN4bHwkFGiu6u23yHvD8xLR/D06V9BsSMjw5jilq+sLm1HZt9x5wDcT2ZEXWmBlBKlZtudS4OuaN/wNnPY4S43Bc9Kmuuo/9UU= Received: by 10.140.251.1 with SMTP id y1mr548341rvh.1189134392930; Thu, 06 Sep 2007 20:06:32 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Thu, 6 Sep 2007 20:06:32 -0700 (PDT) Message-ID: <632825b40709062006n6d612c73r13c03aa16a6d5c2d@mail.gmail.com> Date: Fri, 7 Sep 2007 00:06:32 -0300 From: "William Grzybowski" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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: Fri, 07 Sep 2007 03:06:33 -0000 Hi all, I was looking about powerd and i saw something about it in the website (ideas section). So, if no one [already wrote|is writing] it I was wondering if i could try to write something for it. If it is possible I would ask for some early patches... Bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 06:15:34 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 C47F016A419; Fri, 7 Sep 2007 06:15:34 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9911113C46E; Fri, 7 Sep 2007 06:15:34 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l876FYX1026429; Fri, 7 Sep 2007 06:15:34 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l876FYNg026425; Fri, 7 Sep 2007 06:15:34 GMT (envelope-from remko) Date: Fri, 7 Sep 2007 06:15:34 GMT Message-Id: <200709070615.l876FYNg026425@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/116169: [PATCH] acpi_ibm => psm0 not found problem 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, 07 Sep 2007 06:15:34 -0000 Synopsis: [PATCH] acpi_ibm => psm0 not found problem Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Fri Sep 7 06:15:18 UTC 2007 Responsible-Changed-Why: Reassign to ACPI team http://www.freebsd.org/cgi/query-pr.cgi?pr=116169 From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 06:52:12 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 2A26D16A417 for ; Fri, 7 Sep 2007 06:52:12 +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 E93E013C4B3 for ; Fri, 7 Sep 2007 06:52:11 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 6699 invoked from network); 7 Sep 2007 06:52:06 -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; 7 Sep 2007 06:52:06 -0000 Message-ID: <46E0F352.4090604@root.org> Date: Thu, 06 Sep 2007 23:44:34 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: William Grzybowski References: <632825b40709062006n6d612c73r13c03aa16a6d5c2d@mail.gmail.com> In-Reply-To: <632825b40709062006n6d612c73r13c03aa16a6d5c2d@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: 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: Fri, 07 Sep 2007 06:52:12 -0000 William Grzybowski wrote: > Hi all, > > I was looking about powerd and i saw something about it in the website > (ideas section). > So, if no one [already wrote|is writing] it I was wondering if i could try > to write something for it. > If it is possible I would ask for some early patches... > > Bye. > Nothing yet, read the Summer of Code description and go at it. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 14:01:39 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 ABE1216A468 for ; Fri, 7 Sep 2007 14:01:39 +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 6188C13C480 for ; Fri, 7 Sep 2007 14:01:39 +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 1ITe35-0000KJ-GP; Fri, 07 Sep 2007 16:39:11 +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 l87Dd1hP090794; Fri, 7 Sep 2007 16:39:01 +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 l87Dd1Et090793; Fri, 7 Sep 2007 16:39:01 +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: Fri, 7 Sep 2007 16:39:01 +0300 From: Kostik Belousov To: Nate Lawson Message-ID: <20070907133901.GL53667@deviant.kiev.zoral.com.ua> References: <46E0777A.8070901@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AGBBLMjITsWHeOTZ" Content-Disposition: inline In-Reply-To: <46E0777A.8070901@root.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 6f32a619495bd298c8ed4cb100af0918 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1448 [September 7 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: Fri, 07 Sep 2007 14:01:39 -0000 --AGBBLMjITsWHeOTZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --AGBBLMjITsWHeOTZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG4VR0C3+MBN1Mb4gRAhBEAJ45Z0nSQC0KmE7SZ8FzsO/IGIF9+ACgz06G WnZnKNF3YLngTp7ayVFWKus= =sgd4 -----END PGP SIGNATURE----- --AGBBLMjITsWHeOTZ-- From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 15:18:20 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 6477016A417 for ; Fri, 7 Sep 2007 15:18:20 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 45AFC13C45A for ; Fri, 7 Sep 2007 15:18:20 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so441991rvb for ; Fri, 07 Sep 2007 08:18:10 -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=WeFlSH0vdSQXVYJYF15pW19kXBEu4PtangqjEs9T8WY=; b=j78Q9knhhyzw0VfRoQZNX0EE5j6ZTZe7wz/YvBhy4SsmOHCMG0gBF1Q9DobIvFOmYHcfH2loqkP4GI0aNsyEn6+xv2WPG2SyKxBEBiJaLHQNQuHKgMuGGKldTrmquN86ZGjDyakdoZZPmFaOvcOeHMAukYwoRx0JymzEDMkL+Ss= 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=QESA720hmDL+IZpkvCzBVhW71f9mCuvaYNWADAr7m+COrlHkugon5K4WZQ9B4KPPxhB4iRdXlQw7cDgaT4aK0Yxu96faf4JYRzqYF153FV0iQih5o8nSTehTJR1ResNk8K9Ul4/QZ32PMCS5Ld/BQiWgMz1eciFOXBv/dGIrfrY= Received: by 10.140.174.11 with SMTP id w11mr751415rve.1189176749501; Fri, 07 Sep 2007 07:52:29 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Fri, 7 Sep 2007 07:52:29 -0700 (PDT) Message-ID: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> Date: Fri, 7 Sep 2007 11:52:29 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <46E07AAF.2060000@root.org> MIME-Version: 1.0 References: <46E0777A.8070901@root.org> <46E07AAF.2060000@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, 07 Sep 2007 15:18:20 -0000 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 I tried the 4 test runs which you mentioned , when I boot with both debug.acpi (burst and polled = 1) I got a kernel panic but i couldn't save the backtrace, but it was about _sx_xlock_hard in recursed on non-recursive function, line 209 on acpi_ec.c I'm send links for 3 verbose boot's (i couldnt for burst and polled because the panic) if you want to take a look.. http://www.inf.ufpr.br/wg06/dmesg-acpi-ec.gz http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.gz Thanks, bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Curitiba/PR - Brazil From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 20:44:04 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 E874616A41B for ; Fri, 7 Sep 2007 20:44:04 +0000 (UTC) (envelope-from cnszym@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 783DC13C428 for ; Fri, 7 Sep 2007 20:44:03 +0000 (UTC) (envelope-from cnszym@gmail.com) Received: by nf-out-0910.google.com with SMTP id k4so471389nfd for ; Fri, 07 Sep 2007 13:44: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=lFza9SLFTeZJumDyNzSGTXzjlLZmXZRWr4JZAD63vo8=; b=jvRzNuHjPjrxHNzN21aIAjZi+Kpv2XwdkHXavKVGADmGbbLrfhfYAq/foFVbxxzVCOeBE+9Ciqgqzca9OBaQRpqv3UOBRcBk6CFzbsegvemKjaX9PI58++AdpT2nm87kwy3j5ZVYkOr5HNtlgfV8zU5Ctus2wjvd+WACEDQjhBk= 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=VMnC/C9Lr4oUMn77YZDkZjogcfMa50CAzAyjuxdOpE+5csd0vVyPMMQuPUKEllcdGzFLv6eSJ3WUBBetfbyuzAKXRZCrUjB2WjkByLMQ5s8nKzg0Wva+5YOkA35BrxdVJrAktydzNtvkOssvzYKwUdAVCvHkJ9Shg3E5KrjlSJ4= Received: by 10.78.130.6 with SMTP id c6mr908613hud.1189196093921; Fri, 07 Sep 2007 13:14:53 -0700 (PDT) Received: by 10.78.143.3 with HTTP; Fri, 7 Sep 2007 13:14:53 -0700 (PDT) Message-ID: Date: Fri, 7 Sep 2007 22:14:53 +0200 From: "Cyrille Szymanski" To: "William Grzybowski" , freebsd-acpi@freebsd.org In-Reply-To: <632825b40709071127v63100e16i4fe4c006f96fd3ff@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <632825b40709062006n6d612c73r13c03aa16a6d5c2d@mail.gmail.com> <46E0F352.4090604@root.org> <632825b40709071127v63100e16i4fe4c006f96fd3ff@mail.gmail.com> Cc: 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: Fri, 07 Sep 2007 20:44:05 -0000 > 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 'conservative' modes but maybe they are worth a try. As I understand it, FreeBSD lacks only the 'ondemand' mode ? Bye -- Cyrille From owner-freebsd-acpi@FreeBSD.ORG Fri Sep 7 21:37:31 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 55FCA16A419 for ; Fri, 7 Sep 2007 21:37:31 +0000 (UTC) (envelope-from SRS0=1c7992841f4d63d317abefcaa6afba2f81a3eef0=451=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id CC50313C46C for ; Fri, 7 Sep 2007 21:37:30 +0000 (UTC) (envelope-from SRS0=1c7992841f4d63d317abefcaa6afba2f81a3eef0=451=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id MES70425; Fri, 07 Sep 2007 14:37:25 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id F1D384500E; Fri, 7 Sep 2007 14:37:24 -0700 (PDT) To: "Cyrille Szymanski" In-Reply-To: Your message of "Fri, 07 Sep 2007 22:14:53 +0200." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1189201044_36704P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 07 Sep 2007 14:37:24 -0700 From: "Kevin Oberman" Message-Id: <20070907213724.F1D384500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Cyrille Szymanski X-To_Domain: gmail.com X-To: "Cyrille Szymanski" X-To_Email: cnszym@gmail.com X-To_Alias: cnszym 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: Fri, 07 Sep 2007 21:37:31 -0000 --==_Exmh_1189201044_36704P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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 > 'conservative' modes but maybe they are worth a try. As I understand > it, FreeBSD lacks only the 'ondemand' mode ? 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1189201044_36704P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFG4cSUkn3rs5h7N1ERAlcaAKCCyAldmCMMRqBNY3e4JyYsKxC9mgCgpZSX QxNk42y3CO1tmr7aPU75zQk= =Eoe2 -----END PGP SIGNATURE----- --==_Exmh_1189201044_36704P-- From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 02:41:34 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 847CD16A46B for ; Sat, 8 Sep 2007 02:41:34 +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 544F713C461 for ; Sat, 8 Sep 2007 02:41:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 96174 invoked from network); 8 Sep 2007 02:41:35 -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; 8 Sep 2007 02:41:35 -0000 Message-ID: <46E20A1D.7050608@root.org> Date: Fri, 07 Sep 2007 19:34:05 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sat, 08 Sep 2007 02:41:34 -0000 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. > > 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 Are those errors new or have they always been there? I noticed with the "polled" tunable set, it appears to go away. Is this right or are there errors later in the dmesg? > I tried the 4 test runs which you mentioned , when I boot with both > debug.acpi (burst and polled = 1) I got a kernel panic but i couldn't > save the backtrace, but it was about _sx_xlock_hard in recursed on > non-recursive function, line 209 on acpi_ec.c If you could try this again and get the full panic message, that would help a lot. I need both places the sx was locked, not just one. It usually will report something like "attempt to acquire sx at XXX, previously acquired at YYY". I need both values to figure out what lock order is happening on your system. > I'm send links for 3 verbose boot's (i couldnt for burst and polled > because the panic) if you want to take a look.. > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec.gz > > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.gz > One thing I noted in your dmesg for the polled case was the "acpi_ec0: warning: EC done before starting event wait" message. That tells me your system probably needs some extra checking to figure out when the status is actually ready, but that's a complicated case I'm not sure how to solve yet. But did any other errors show up in that case? Did thermal/battery status get reported correctly? One thing you could do to help me is to build the kernel and acpi module with: options KTR options KTR_COMPILE=KTR_DEV options KTR_ENTRIES=65536 Then, boot to multi-user for each of the 4 cases I mentioned above (don't bother for the panic case) and run: ktrdump -rt | sort -n | gzip -9c > foo.ktr I'll then be able to see more detail about how the EC is behaving on your system. Thanks, -- Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 09:00:34 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 9B86016A420 for ; Sat, 8 Sep 2007 09:00:34 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by mx1.freebsd.org (Postfix) with ESMTP id 20A9A13C428 for ; Sat, 8 Sep 2007 09:00:33 +0000 (UTC) (envelope-from mikael.ikivesi@pp.inet.fi) Received: from hoasb-ff0add00-184.dhcp.inet.fi (80.221.10.184) by pne-smtpout3-sn1.fre.skanova.net (7.2.075) id 46CBD460000D84A7 for freebsd-acpi@freebsd.org; Sat, 8 Sep 2007 09:51:32 +0200 From: Mikael Ikivesi To: freebsd-acpi@freebsd.org Date: Sat, 8 Sep 2007 10:54:13 +0300 User-Agent: KMail/1.9.5 References: <46E0777A.8070901@root.org> In-Reply-To: <46E0777A.8070901@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709081054.14073.mikael.ikivesi@pp.inet.fi> 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: Sat, 08 Sep 2007 09:00:34 -0000 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) ----AND--- Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #3: Sat Sep 8 00:44:11 EEST 2007 root@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80a93000. Calibrating clock(s) ... i8254 clock: 1193164 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 800009844 Hz CPU: Mobile AMD Athlon(tm) 64 Processor 3700+ (800.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20f42 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 926576640 (883 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000b90000 - 0x0000000036422fff, 898183168 bytes (219283 pages) avail memory = 892522496 (851 MB) ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 ACPI: RSDP @ 0x0xf7ee0/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x37eaa47e/0x0034 (v 1 PTLTD RSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x37eaedbd/0x0074 (v 1 FUJ W37 0x06040000 W37 0x000F4240) ACPI: DSDT @ 0x0x37eaa4b2/0x490B (v 1 FUJ W37 0x06040000 MSFT 0x0100000E) ACPI: FACS @ 0x0x37eaffc0/0x0040 ACPI: SSDT @ 0x0x37eaee31/0x0139 (v 1 PTLTD POWERNOW 0x06040000 LTP 0x00000001) ACPI: APIC @ 0x0x37eaef6a/0x005A (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: MCFG @ 0x0x37eaefc4/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 21 ioapic0: intpin 9 disabled lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan_amrr: wlan: <802.11 Link Layer> ath_rate: version 1.2 kbd: new array size 4 kbd1 at kbdmux0 mem: null: nfslock: pseudo-device random: io: ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a104 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=59501002) AcpiOsDerivePciId: \_SB_.PCI0.SATA.SATX -> bus 0 dev 18 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SAT2.SATX -> bus 0 dev 17 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: \_SB_.PCI0.IDE_.IDE_ -> bus 0 dev 20 func 1 AcpiOsDerivePciId: \_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi0: reservation of 0, 1000 (3) failed ACPI timer: 0/12 0/11 0/11 0/11 0/11 0/11 0/11 0/11 0/11 0/11 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1002, dev=0x5950, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x5a3f, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4374, revid=0x00 bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type Memory, range 32, base 0xc0000000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4375, revid=0x00 bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[10]: type Memory, range 32, base 0xc0001000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4373, revid=0x00 bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0013, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xc0002000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4372, revid=0x11 bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0x8400, size 4, enabled map[14]: type Memory, range 32, base 0xc0003000, size 10, enabled found-> vendor=0x1002, dev=0x4376, revid=0x00 bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 MSI supports 1 message map[20]: type I/O Port, range 32, base 0x8410, size 4, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4377, revid=0x00 bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4371, revid=0x00 bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4370, revid=0x02 bus=0, slot=20, func=5 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 MSI supports 1 message map[10]: type Memory, range 32, base 0xc0003400, size 8, enabled pcib0: matched entry for 0.20.INTB pcib0: slot 20 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4378, revid=0x02 bus=0, slot=20, func=6 class=07-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 MSI supports 1 message map[10]: type Memory, range 32, base 0xc0003800, size 8, enabled pcib0: matched entry for 0.20.INTB pcib0: slot 20 INTB hardwired to IRQ 17 found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x9000-0x9fff pcib1: memory decode 0xc0100000-0xc01fffff pcib1: prefetched decode 0xc8000000-0xcfffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x5955, revid=0x00 bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xc8000000, size 27, enabled pcib1: requested memory range 0xc8000000-0xcfffffff: good map[14]: type I/O Port, range 32, base 0x9000, size 8, enabled pcib1: requested I/O range 0x9000-0x90ff: in range map[18]: type Memory, range 32, base 0xc0100000, size 16, enabled pcib1: requested memory range 0xc0100000-0xc010ffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 17 vgapci0: port 0x9000-0x90ff mem 0xc8000000-0xcfffffff,0xc0100000-0xc010ffff irq 17 at device 5.0 on pci1 ohci0: mem 0xc0000000-0xc0000fff irq 19 at device 19.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0000000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xc0001000-0xc0001fff irq 19 at device 19.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0001000 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 4 ports with 4 removable, self powered ehci0: mem 0xc0002000-0xc0002fff irq 19 at device 19.2 on pci0 ehci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0002000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 8 ports with 8 removable, self powered pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8410-0x841f irq 16 at device 20.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8410 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 50 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 51 ata1: [MPSAFE] ata1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib2: at device 20.4 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xa000-0xafff pcib2: memory decode 0xc0200000-0xc02fffff pcib2: no prefetched decode pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x14e4, dev=0x4318, revid=0x02 bus=2, slot=5, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xc0204000, size 13, enabled pcib2: requested memory range 0xc0204000-0xc0205fff: good pcib2: matched entry for 2.5.INTA pcib2: slot 5 INTA hardwired to IRQ 20 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=2, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xa000, size 8, enabled pcib2: requested I/O range 0xa000-0xa0ff: in range map[14]: type Memory, range 32, base 0xc0208000, size 8, enabled pcib2: requested memory range 0xc0208000-0xc02080ff: good pcib2: matched entry for 2.7.INTA pcib2: slot 7 INTA hardwired to IRQ 23 found-> vendor=0x104c, dev=0x8031, revid=0x00 bus=2, slot=9, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0, size 12, enabled found-> vendor=0x104c, dev=0x8032, revid=0x00 bus=2, slot=9, func=2 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0016, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xc0208800, size 11, enabled pcib2: requested memory range 0xc0208800-0xc0208fff: good map[14]: type Memory, range 32, base 0xc0200000, size 14, enabled pcib2: requested memory range 0xc0200000-0xc0203fff: good pcib2: matched entry for 2.9.INTC pcib2: slot 9 INTC hardwired to IRQ 21 found-> vendor=0x104c, dev=0x8033, revid=0x00 bus=2, slot=9, func=3 class=01-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xc0206000, size 13, enabled pcib2: requested memory range 0xc0206000-0xc0207fff: good pcib2: matched entry for 2.9.INTA pcib2: slot 9 INTA hardwired to IRQ 20 pci2: at device 5.0 (no driver attached) rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xa000 pcib2: re0 requested I/O range 0xa000-0xa0ff: in range pcib2: rl0 requested I/O range 0xa000-0xa0ff: in range rl0: port 0xa000-0xa0ff mem 0xc0208000-0xc02080ff irq 23 at device 7.0 on pci2 pcib2: rl0 requested I/O range 0xa000-0xa0ff: in range miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:0a:e4:ac:90:fa ioapic0: routing intpin 23 (PCI IRQ 23) to vector 52 rl0: [MPSAFE] rl0: [ITHREAD] cbb0: at device 9.0 on pci2 pcib2: cbb0 requested memory range 0xc0200000-0xc02fffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xc0209000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.9.INTA pcib2: slot 9 INTA hardwired to IRQ 20 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 53 cbb0: [MPSAFE] cbb0: [ITHREAD] cbb0: PCI Configuration space: 0x00: 0x8031104c 0x02100007 0x06070000 0x00824010 0x10: 0xc0209000 0x020000a0 0x20040302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400114 0x40: 0x10921734 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0844d061 0x00000000 0x001f0000 0x010a1b22 0x90: 0x606402c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 pci2: at device 9.2 (no driver attached) pci2: at device 9.3 (no driver attached) pci0: at device 20.5 (no driver attached) pci0: at device 20.6 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 54 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 55 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 battery0: on acpi0 acpi_acad0: on acpi0 ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xdc000-0xdffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: probe failed test(s): 0 1 2 4 6 7 9 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 100001242 hz Timecounter "TSC" frequency 800009844 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached battery0: battery initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire acpi_acad0: acline initialization start ad0: setting PIO4 on IXP400 chip ad0: setting UDMA100 on IXP400 chip ad0: 76319MB at ata0-master UDMA100 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: Silicon Image check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on IXP400 chip acd0: setting UDMA33 on IXP400 chip acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc GEOM_LABEL: Label for provider ad0s1 is ext2fs/root. battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times GEOM_LABEL: Label for provider ad0s5 is ext2fs/tmp. GEOM_LABEL: Label for provider ad0s7 is reiserfs/home. GEOM_LABEL: Label for provider ad0s8 is ext2fs/taotao. GEOM_LABEL: Label for provider ad0s9 is ext2fs/portage. acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error (probe0:ata1:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata1:0:0:0): error 6 (probe0:ata1:0:0:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 (probe0:ata1:0:0:0): error 22 (probe0:ata1:0:0:0): Unretryable Error pass0 at ata1 bus 0 target 0 lun 0 pass0: RemovGEOM: new disk cd0 able CD-ROM SCSI-0 device pass0: 33.000MB/s transfers ATA PseudoRAID loaded (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: WITNESS option enabled, expect reduced performance. (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error (cd0:ata1:0:0:0): error 6 (cd0:ata1:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/ad0s3a start_init: trying /sbin/init <118>Loading configuration files. <118>kernel dumps on /dev/ad0s3b <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. <118>swapon: adding /dev/ad0s3b as swap device <118>Starting file system checks: <118>/dev/ad0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s3a: clean, 67767 free (935 frags, 8354 blocks, 0.4% fragmentation) <118>/dev/ad0s3e: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s3e: clean, 253782 free (38 frags, 31718 blocks, 0.0% fragmentation) <118>/dev/ad0s3f: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s3f: clean, 4482975 free (59103 frags, 552984 blocks, 1.0% fragmentation) <118>/dev/ad0s3d: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s3d: clean, 908024 free (144 frags, 113485 blocks, 0.0% fragmentation) <118>Setting hostuuid: 962fc960-322a-11da-b7f3-aa7b8b2b72d7. <118>Setting hostid: 0x584b66d1. <118>Mounting local file systems: <118>. <118>/etc/rc: WARNING: $hostname is not set -- see rc.conf(5). <118>net.inet6.ip6.auto_linklocal: <118>1 <118> -> <118>0 <118> <118>lo0: flags=8049 metric 0 mtu 16384 <118> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 <118> inet6 ::1 prefixlen 128 <118> inet 127.0.0.1 netmask 0xff000000 <118>Additional routing options: <118>. <118>Starting devd. <118>hw.acpi.cpu.cx_lowest: <118>C1 <118> -> <118>C1 <118> <118>Additional IP options: <118>. <118>Mounting NFS file systems: <118>. <118>Creating and/or trimming log files: <118>. <118>Starting syslogd. <118>Checking for core dump on /dev/ad0s3b... <118>savecore: no dumps found <118>ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib <118>32-bit compatibility ldconfig path: /usr/lib32 <118>Initial amd64 initialization: <118>. <118>Additional ABI support: <118>. <118>Starting named. <118>Clearing /tmp (X related). <118>Starting local daemons: <118>. <118>Updating motd <118>. <118>Mounting late file systems: <118>. <118>Configuring syscons: <118> keymap <118> blanktime <118>. <118>Starting cron. <118>Local package initialization: <118>. <118>Starting default moused: <118>. <118>Starting background file system checks in 60 seconds. <118> <118>Sat Sep 8 10:03:15 EEST 2007 From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 17:43:21 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 4140716A417 for ; Sat, 8 Sep 2007 17:43:21 +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 F3E8813C45D for ; Sat, 8 Sep 2007 17:43:20 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 77461 invoked from network); 8 Sep 2007 17:43:21 -0000 Received: from unknown (HELO ?192.168.1.103?) (nate-mail@75.62.242.158) by root.org with ESMTPA; 8 Sep 2007 17:43:21 -0000 Message-ID: <46E2DF2E.9000704@root.org> Date: Sat, 08 Sep 2007 10:43:10 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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.3 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: Sat, 08 Sep 2007 17:43:21 -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... Excellent. > dmesg still shows this: > acpi0: reservation of 0, 1000 (3) failed Not sure which driver that inhibits for you. Still should be investigated separately. > 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. The patch doesn't re-enable polled mode during shutdown so those were timeout messages. I have a small revision to the patch that does this, I just have to post it. > 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! This is a separate issue. Suspend/resume is not yet implemented on amd64, nor is it implemented for multi-core machines. Still, it should not panic so I need to look into why that occurred. The request should simply be rejected as "not implemented". -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 17:46:13 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 415DE16A420 for ; Sat, 8 Sep 2007 17:46:13 +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 DFBB613C46E for ; Sat, 8 Sep 2007 17:46:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 77585 invoked from network); 8 Sep 2007 17:46:13 -0000 Received: from unknown (HELO ?192.168.1.103?) (nate-mail@75.62.242.158) by root.org with ESMTPA; 8 Sep 2007 17:46:13 -0000 Message-ID: <46E2DFDB.7050107@root.org> Date: Sat, 08 Sep 2007 10:46:03 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: yousif@alumni.jmu.edu References: <46E0777A.8070901@root.org> <1189273154.1805.15.camel@localhost> In-Reply-To: <1189273154.1805.15.camel@localhost> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sat, 08 Sep 2007 17:46:13 -0000 Yousif Hassan wrote: > Since you asked for testers on Compaqs, I tried this out on my Compaq > nx6110 under 6.2. > > W/ this laptop, battery status was always close to correct before, but > it does appear that your patch improves things somewhat - I no longer > get 95-99% full being reported when the battery is actually at 100% > (don't know if that's a coincidence or an intended benefit). Also, the > "time remaining" calculations appear to be slightly more accurate, so > this is great. Yes, battery and temperature reporting are usually the factors that would have problems without the patch. The patch is not intended to fix anything else. > This patch does not fix the errors of: > acpi0: on motherboard > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > acpi_bus_number: can't get _ADR > > (these have never given me too much grief) but that probably wasn't the > purpose of this patch either. ;) I don't think that it added any new > error msgs. Those messages can be harmless, but occasionally indicate a buggy BIOS. If your devices work, they can be ignored. > Obviously, suspend/resume and hibernate are still woefully broken on > this laptop (as is noted in the PRs), so I didn't try those again. I > have not tried 7.x (CURRENT) on this laptop either. If suspend/resume > gets implemented with the new ACPI code in 7.x I will certainly be > motivated to upgrade. Ok. -Nate From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 18:05:45 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 A3DB116A419 for ; Sat, 8 Sep 2007 18:05:45 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: from coruscant.far-far-away.us (coruscant.far-far-away.us [70.91.196.65]) by mx1.freebsd.org (Postfix) with SMTP id 4C19E13C46B for ; Sat, 8 Sep 2007 18:05:45 +0000 (UTC) (envelope-from yousif@alumni.jmu.edu) Received: (qmail 99465 invoked from network); 8 Sep 2007 13:34:36 -0400 Received: from alderaan.far-far-away.us (HELO ?192.168.0.4?) (192.168.0.4) by coruscant.far-far-away.us with SMTP; 8 Sep 2007 13:34:36 -0400 From: Yousif Hassan To: Nate Lawson In-Reply-To: <46E0777A.8070901@root.org> References: <46E0777A.8070901@root.org> Content-Type: text/plain Date: Sat, 08 Sep 2007 13:39:14 -0400 Message-Id: <1189273154.1805.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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 Reply-To: yousif@alumni.jmu.edu List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2007 18:05:45 -0000 Since you asked for testers on Compaqs, I tried this out on my Compaq nx6110 under 6.2. W/ this laptop, battery status was always close to correct before, but it does appear that your patch improves things somewhat - I no longer get 95-99% full being reported when the battery is actually at 100% (don't know if that's a coincidence or an intended benefit). Also, the "time remaining" calculations appear to be slightly more accurate, so this is great. This patch does not fix the errors of: acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR (these have never given me too much grief) but that probably wasn't the purpose of this patch either. ;) I don't think that it added any new error msgs. Obviously, suspend/resume and hibernate are still woefully broken on this laptop (as is noted in the PRs), so I didn't try those again. I have not tried 7.x (CURRENT) on this laptop either. If suspend/resume gets implemented with the new ACPI code in 7.x I will certainly be motivated to upgrade. On Thu, 2007-09-06 at 14:56 -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). > > 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. > > - 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) > > > -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"