cvs commit: src/sys/dev/acpica acpi_pcib_acpi.c src/sys/i386/pci pci_bus.c

[M. Warner Losh]

In message: <200509160702.j8G72TBv063544 at repoman.freebsd.org>
            Warner Losh <imp at FreeBSD.org> writes:
: imp         2005-09-16 07:02:29 UTC
: 
:   FreeBSD src repository
: 
:   Modified files:
:     sys/dev/acpica       acpi_pcib_acpi.c 
:     sys/i386/pci         pci_bus.c 
:   Log:
:   Commit a workaround to a problem with resource allocation.  This helps
:   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@

for those interested in the omitted footnote:

[*] and also without its first usb controller: uhci0 failed to attach.

I don't think this is worthy of a forced commit, but I know how some
people are when they see dangling references...

Warner