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

[Nate Lawson]

M. Warner Losh wrote:
> 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...

At some point, I may implement a similar workaround as Windows XP.  It 
blocks access by AML to the following port ranges.

http://www.softwaretipsandtricks.com/forum/printthread.php?t=1674

Address       Function                 Comments
0x000 – 0x00F DMA Controller 1
0x020 – 0x021 PIC                      Access is never allowed*
0x040 – 0x043 System Timer 1
0x048 – 0x04B Timer 2 Failsafe
0x070 – 0x071 System CMOS, RTC
0x074 – 0x076 Extended CMOS
0x081 – 0x083 DMA1 Page Registers
0x087         DMA1 CH0 Low Page
0x089         DMA2 CH2 Low Page
0x08A – 0x08B DMA2 CH3 Low Page,
0x08F         DMA2 Low Page Refresh
0x090 – 0x091 Arbitration Control Port  Card Select Feedback
0x093 – 0x094 Reserved System Board Setup
0x096 – 0x097 POS Channel Select
0x0A0 – 0x0A1 Cascaded PIC              Access is never allowed*
0x0C0 – 0x0DF ISA DMA
0x4D0 – 0x4D1 PIC Edge/Level CR         Access is never allowed*
0xCF8 – 0xD00 PCI Configuration Space

*Read or write accesses to these ports are always blocked, regardless of 
the BIOS use of the _OSI method.

Of course, you're describing device resources, but it seems like a 
similar issue.  If someone else wants to do this, let me know.

-- 
Nate