From owner-freebsd-acpi@FreeBSD.ORG Mon Jun 13 11:06:58 2011 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 016901065676 for ; Mon, 13 Jun 2011 11:06:58 +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 DBC3A8FC08 for ; Mon, 13 Jun 2011 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5DB6v99091993 for ; Mon, 13 Jun 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5DB6vri091991 for freebsd-acpi@FreeBSD.org; Mon, 13 Jun 2011 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jun 2011 11:06:57 GMT Message-Id: <201106131106.p5DB6vri091991@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 freebsd-acpi@FreeBSD.org 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, 13 Jun 2011 11:06:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/73823 acpi [request] acpi / power-on by timer support o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 41 problems total. From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 15 13:57:59 2011 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 A5DCE1065673 for ; Wed, 15 Jun 2011 13:57:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7EF1A8FC1E for ; Wed, 15 Jun 2011 13:57:59 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 35CA746B38 for ; Wed, 15 Jun 2011 09:57:59 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C50498A01F for ; Wed, 15 Jun 2011 09:57:58 -0400 (EDT) From: John Baldwin To: acpi@freebsd.org Date: Wed, 15 Jun 2011 09:57:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201106150957.58049.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 15 Jun 2011 09:57:58 -0400 (EDT) Cc: Subject: Only attach device_t objects to ACPI devices with a _HID X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:57:59 -0000 The ACPI bus driver currently adds a device node (device_t) for every Device() object in the ACPI namespace. However, the ACPI namespace enumerates devices on other buses (such as PCI) that are self-enumerating. In fact, we have code in the ACPI PCI bus driver to reclaim the device nodes for PCI devices and associate the PCI-enumerated device nodes with ACPI handles instead. In practice no device driver can attach to an ACPI device node unless it has _HID or _CID methods, so having ACPI device_t objects for nodes without an ID isn't really useful. My changes to make the ACPI bus driver reserve resources for devices has turned up some cases where it is actually harmful as well. It seems a few BIOSes actually use _CRS to list resources for a PCI device that are not managed via a BAR. (I've see this at least twice so far.) Two things happen as a result: 1) the resources are "orphaned" when the ACPI device_t is removed and replaced by the PCI device_t. As a result, devinfo -r claims they are associated with some other device (whatever happens to reuse that device_t pointer). 2) The resources can be allocated at the wrong place in the tree. I had a recent thread on current@ where 2) interacted badly with the NEW_PCIB changes to the PCI-PCI bridge driver. Because the ACPI-enumerated device_t hangs off acpi0, it is not "behind" the PCI-PCI bridges. In the case of the thread, a PCI device behind a bridge was allocating some IO port resources via _CRS that were in the parent bridge's window. However, because the ACPI device_t was off of acpi0, it turned into a resource conflict since the resources were not allocated from the PCI-PCI bridge but from nexus0 directly. What I am proposing to do is to change the ACPI bus driver to only add device_t objects for Device() nodes that have a _HID or _CID. This should not break any devices that have a current driver, but it will avoid having ACPI attach to PCI devices. This does mean that _CRS is currently ignored for PCI devices. My feeling on that is that if we do feel that is important to reserve those resources, we should handle that in the ACPI PCI bus driver itself instead (it can examine _CRS for those devices and allocate resources if we so choose). It does strike me as odd that BIOSes are assigning resources to PCI devices via _CRS and I wonder if it is truly valid or it it should just be ignored. The patch in question: Index: acpi.c =================================================================== --- acpi.c (revision 223082) +++ acpi.c (working copy) @@ -151,6 +151,7 @@ static ACPI_STATUS acpi_EnterSleepState(struct acpi_softc *sc, int state); static void acpi_shutdown_final(void *arg, int howto); static void acpi_enable_fixed_events(struct acpi_softc *sc); +static BOOLEAN acpi_has_hid(ACPI_HANDLE handle); static int acpi_wake_sleep_prep(ACPI_HANDLE handle, int sstate); static int acpi_wake_run_prep(ACPI_HANDLE handle, int sstate); static int acpi_wake_prep_walk(int sstate); @@ -1855,6 +1856,13 @@ break; if (acpi_parse_prw(handle, &prw) == 0) AcpiSetupGpeForWake(handle, prw.gpe_handle, prw.gpe_bit); + + /* + * Ignore devices that do not have a _HID or _CID. They should + * be discovered by other buses (e.g. the PCI bus driver). + */ + if (!acpi_has_hid(handle)) + break; /* FALLTHROUGH */ case ACPI_TYPE_PROCESSOR: case ACPI_TYPE_THERMAL: @@ -2043,6 +2051,30 @@ } /* + * Returns true if a device has at least one valid device ID. + */ +static BOOLEAN +acpi_has_hid(ACPI_HANDLE h) +{ + ACPI_DEVICE_INFO *devinfo; + BOOLEAN ret; + + if (h == NULL || + ACPI_FAILURE(AcpiGetObjectInfo(h, &devinfo))) + return (FALSE); + + ret = FALSE; + if ((devinfo->Valid & ACPI_VALID_HID) != 0) + ret = TRUE; + else if ((devinfo->Valid & ACPI_VALID_CID) != 0) + if (devinfo->CompatibleIdList.Count > 0) + ret = TRUE; + + AcpiOsFree(devinfo); + return (ret); +} + +/* * Match a HID string against a handle */ BOOLEAN Index: acpi_pci.c =================================================================== --- acpi_pci.c (revision 223082) +++ acpi_pci.c (working copy) @@ -209,38 +209,24 @@ device_t child; /* - * Lookup and remove the unused device that acpi0 creates when it walks - * the namespace creating devices. + * Occasionally a PCI device may show up as an ACPI device + * with a _HID. (For example, the TabletPC TC1000 has a + * second PCI-ISA bridge that has a _HID for an + * acpi_sysresource device.) In that case, leave ACPI-CA's + * device data pointing at the ACPI-enumerated device. */ child = acpi_get_device(handle); if (child != NULL) { - if (device_is_alive(child)) { - /* - * The TabletPC TC1000 has a second PCI-ISA bridge - * that has a _HID for an acpi_sysresource device. - * In that case, leave ACPI-CA's device data pointing - * at the ACPI-enumerated device. - */ - device_printf(child, - "Conflicts with PCI device %d:%d:%d\n", - pci_get_bus(pci_child), pci_get_slot(pci_child), - pci_get_function(pci_child)); - return; - } KASSERT(device_get_parent(child) == devclass_get_device(devclass_find("acpi"), 0), ("%s: child (%s)'s parent is not acpi0", __func__, acpi_name(handle))); - device_delete_child(device_get_parent(child), child); + return; } /* * Update ACPI-CA to use the PCI enumerated device_t for this handle. */ - status = AcpiDetachData(handle, acpi_fake_objhandler); - if (ACPI_FAILURE(status)) - printf("WARNING: Unable to detach object data from %s - %s\n", - acpi_name(handle), AcpiFormatException(status)); status = AcpiAttachData(handle, acpi_fake_objhandler, pci_child); if (ACPI_FAILURE(status)) printf("WARNING: Unable to attach object data to %s - %s\n", -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 15 16:48:11 2011 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 ADBAC106566B for ; Wed, 15 Jun 2011 16:48:11 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.rootlabs.com (rootlabs.com [208.72.84.106]) by mx1.freebsd.org (Postfix) with ESMTP id 872018FC20 for ; Wed, 15 Jun 2011 16:48:11 +0000 (UTC) Received: from airmac.local (dsl081-053-082.sfo1.dsl.speakeasy.net [64.81.53.82]) by mail.rootlabs.com (Postfix) with ESMTPSA id A212B153AF; Wed, 15 Jun 2011 09:48:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nate Lawson In-Reply-To: <201106150957.58049.jhb@freebsd.org> Date: Wed, 15 Jun 2011 09:48:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201106150957.58049.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) Cc: acpi@freebsd.org Subject: Re: Only attach device_t objects to ACPI devices with a _HID X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:48:11 -0000 On Jun 15, 2011, at 6:57 AM, John Baldwin wrote: > What I am proposing to do is to change the ACPI bus driver to only add=20= > device_t objects for Device() nodes that have a _HID or _CID. This = should not=20 > break any devices that have a current driver, but it will avoid having = ACPI=20 > attach to PCI devices. This does mean that _CRS is currently ignored = for PCI=20 > devices. My feeling on that is that if we do feel that is important = to=20 > reserve those resources, we should handle that in the ACPI PCI bus = driver=20 > itself instead (it can examine _CRS for those devices and allocate = resources > if we so choose). While this should be fine for legacy devices, I do worry about other = synthetic devices, such as CPUs, NUMA zones, etc. Would it be better = just not to attach acpi device_t's to any nodes under PCI busses? Also, it's still possible some PCI devices would have a CID, so you'd = still have to handle this case, right? > It does strike me as odd that BIOSes are assigning resources to PCI = devices=20 > via _CRS and I wonder if it is truly valid or it it should just be = ignored. I think I remember some BIOSes hooking _CRS to do some late allocations. = It's bad behavior, of course, and closely ties their allocation scheme = to the order that WIndows traversed the acpi device tree. -Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 15 20:00:12 2011 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 5F032106564A for ; Wed, 15 Jun 2011 20:00:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1AAC08FC0A for ; Wed, 15 Jun 2011 20:00:11 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B06C346B0D; Wed, 15 Jun 2011 16:00:10 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D36F8A027; Wed, 15 Jun 2011 16:00:10 -0400 (EDT) From: John Baldwin To: Nate Lawson Date: Wed, 15 Jun 2011 14:52:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <201106150957.58049.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106151452.09955.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 15 Jun 2011 16:00:10 -0400 (EDT) Cc: acpi@freebsd.org Subject: Re: Only attach device_t objects to ACPI devices with a _HID X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:00:12 -0000 On Wednesday, June 15, 2011 12:48:09 pm Nate Lawson wrote: > On Jun 15, 2011, at 6:57 AM, John Baldwin wrote: > > What I am proposing to do is to change the ACPI bus driver to only add > > device_t objects for Device() nodes that have a _HID or _CID. This should not > > break any devices that have a current driver, but it will avoid having ACPI > > attach to PCI devices. This does mean that _CRS is currently ignored for PCI > > devices. My feeling on that is that if we do feel that is important to > > reserve those resources, we should handle that in the ACPI PCI bus driver > > itself instead (it can examine _CRS for those devices and allocate resources > > if we so choose). > > While this should be fine for legacy devices, I do worry about other synthetic devices, such as CPUs, NUMA zones, etc. Would it be better just not to attach acpi device_t's to any nodes under PCI busses? This is harder to arrange. Note that the proposed patch only applies to a Device(), not to Processor() or ThermalZone(), etc. objects. I believe though that all such things that you mentioned use either an object type other than ACPI_TYPE_DEVICE, an entirely different table (MADT, SRAT, etc.), or a Device() with a HID or CID. > Also, it's still possible some PCI devices would have a CID, so you'd still have to handle this case, right? Yes, and we already handle that case (there's an older tablet that hung a system resource device off its PCI-ISA bridge). In that case you still (as now) end up with two device_t's, one attached to acpi0, the other attached to the relevant PCI bus. -- John Baldwin