svn commit: r261243 - head/sys/dev/acpica
John Baldwin
jhb at FreeBSD.org
Tue Jan 28 20:53:34 UTC 2014
Author: jhb
Date: Tue Jan 28 20:53:33 2014
New Revision: 261243
URL: http://svnweb.freebsd.org/changeset/base/261243
Log:
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.
Reviewed by: jkim
MFC after: 1 week
Modified:
head/sys/dev/acpica/acpi.c
Modified: head/sys/dev/acpica/acpi.c
==============================================================================
--- head/sys/dev/acpica/acpi.c Tue Jan 28 20:28:32 2014 (r261242)
+++ head/sys/dev/acpica/acpi.c Tue Jan 28 20:53:33 2014 (r261243)
@@ -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);
More information about the svn-src-all
mailing list