From owner-svn-src-all@FreeBSD.ORG Tue Mar 11 14:33:43 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0152AA70; Tue, 11 Mar 2014 14:33:43 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C74E6D0B; Tue, 11 Mar 2014 14:33:42 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s2BEXgO3024819; Tue, 11 Mar 2014 14:33:42 GMT (envelope-from jhb@svn.freebsd.org) Received: (from jhb@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s2BEXgbo024818; Tue, 11 Mar 2014 14:33:42 GMT (envelope-from jhb@svn.freebsd.org) Message-Id: <201403111433.s2BEXgbo024818@svn.freebsd.org> From: John Baldwin Date: Tue, 11 Mar 2014 14:33:42 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-10@freebsd.org Subject: svn commit: r263022 - in stable: 10/sys/dev/acpica 9/sys/dev/acpica X-SVN-Group: stable-10 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 14:33:43 -0000 Author: jhb Date: Tue Mar 11 14:33:42 2014 New Revision: 263022 URL: http://svnweb.freebsd.org/changeset/base/263022 Log: MFC 261243: Some BIOSes incorrectly use standard memory resource ranges to list the memory ranges that they decode for downstream devices rather than creating ResourceProducer range resource entries. The result is that we allocate the full range to the PCI root bridge device causing allocations in child devices to all fail. As a workaround, ignore any standard memory resources on a PCI root bridge device. It is normal for a PCI root bridge to allocate an I/O resource for the I/O ports used for PCI config access, but I have not seen any PCI root bridges that legitimately allocate a memory resource. Modified: stable/10/sys/dev/acpica/acpi.c Directory Properties: stable/10/ (props changed) Changes in other areas also in this revision: Modified: stable/9/sys/dev/acpica/acpi.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/dev/ (props changed) Modified: stable/10/sys/dev/acpica/acpi.c ============================================================================== --- stable/10/sys/dev/acpica/acpi.c Tue Mar 11 13:47:11 2014 (r263021) +++ stable/10/sys/dev/acpica/acpi.c Tue Mar 11 14:33:42 2014 (r263022) @@ -1190,12 +1190,28 @@ acpi_set_resource(device_t dev, device_t struct acpi_softc *sc = device_get_softc(dev); struct acpi_device *ad = device_get_ivars(child); struct resource_list *rl = &ad->ad_rl; + ACPI_DEVICE_INFO *devinfo; u_long end; /* Ignore IRQ resources for PCI link devices. */ if (type == SYS_RES_IRQ && ACPI_ID_PROBE(dev, child, pcilink_ids) != NULL) return (0); + /* + * Ignore memory resources for PCI root bridges. Some BIOSes + * incorrectly enumerate the memory ranges they decode as plain + * memory resources instead of as a ResourceProducer range. + */ + if (type == SYS_RES_MEMORY) { + if (ACPI_SUCCESS(AcpiGetObjectInfo(ad->ad_handle, &devinfo))) { + if ((devinfo->Flags & ACPI_PCI_ROOT_BRIDGE) != 0) { + AcpiOsFree(devinfo); + return (0); + } + AcpiOsFree(devinfo); + } + } + /* If the resource is already allocated, fail. */ if (resource_list_busy(rl, type, rid)) return (EBUSY);