dca2069084
with some Dell servers that booted w/o a problem[*] on 5.4, but failed with 6.0-BETA. On the PCI bus, when we do lazy resource allocation, we narrow the range requested as we pass through bridges to reflect how the bridges are programmed and what addresses they pass. However, when we're doing an allocation on a bus that's directly connected to a host bridge, no such translation can take place. We already had a fallback range for memory requests, but none for ioports. As such, provide a fallback for I/O ports so we don't allocate location 0, which will have undesired side effects when the resources are actually used. This fixes a problem with booting a Dell server with usb in the kernel. However, it is an unsatisfying solution. I don't like the hard coded value, and I think we should start narrowing the resources returned to not be in the so-called isa alias area (where the ranage & 0x0300 must be 0 iirc). Doing such filtering will have to wait for another day. This may be a good 6 candidate, maybe after its had a chance to be refined. Tested by: glebius@ |
||
---|---|---|
.. | ||
Osd | ||
acpi_acad.c | ||
acpi_battery.c | ||
acpi_button.c | ||
acpi_cmbat.c | ||
acpi_cpu.c | ||
acpi_ec.c | ||
acpi_if.m | ||
acpi_isab.c | ||
acpi_lid.c | ||
acpi_package.c | ||
acpi_pci_link.c | ||
acpi_pci.c | ||
acpi_pcib_acpi.c | ||
acpi_pcib_pci.c | ||
acpi_pcib.c | ||
acpi_pcibvar.h | ||
acpi_perf.c | ||
acpi_powerres.c | ||
acpi_quirk.c | ||
acpi_quirks | ||
acpi_resource.c | ||
acpi_thermal.c | ||
acpi_throttle.c | ||
acpi_timer.c | ||
acpi_video.c | ||
acpi.c | ||
acpiio.h | ||
acpivar.h |