Warner Losh wrote:
The ACPI+sio problem is known. I have a motherboard with a similar
problem, though a different brand than yours. I solved it by removing
the ACPI attachment from the sio code. The better solution is to allow
loader hints to override ACPI hints. I tried talking to John Baldwin
about this but didn't get much of a response.
I've tried all suggestions so far, but to no avail on most servers. Too
many broken ACPI implementations I fear... Too bad motherboard vendors
don't take the time to push proper software in their flash.
Right now acpi tells us there's a device, and we use it. Loader hints
should be used to map locations to device instances. It is more
general than just ACPI, however. People want to bind sio to a
specific port that comes out the back. People also want to bind rl0
to the card in slot 3.
Consider my system:
sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.SBRG.UAR1
sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.SBRG.UAR2
On this system, UAR1 is the port that comes out the back, so I have
what I want. However, I'd like to be able to say:
hint.sio.0.at="acpi"
hint.sio.0.location="\_SB_.PCI0.SBRG.UAR2"
or
hint.sio.0.at="acpi"
hint.sio.0.location="UAR2"
or
hint.fxp.0.at="pci"
hint.fxp.0.location="bus=2 slot=3 function=0"
hint.fxp.1.at="pci"
hint.fxp.1.location="pci2:2:0"
Since we really want to map the devices in some arbitrary ACPI tree to
instances in the system, rather than mapping devices that happen to
live at a specific resource address to specific instances in the tree.
However, there are a number of issues in doing this generically and
with error cases. How does one deal with the different syntaxes?
What extensions to the newbus system are there? etc.
Warner
Well, in my case at least, what ACPI says about the sio resources is
simply wrong, and I'm not smart enough to figure out how to correct the
ASL or get it loaded correctly on boot. It would be easier if the
sio-acpi attachment honored the hints that already exist for the purpose
of describing the sio resources. Last I checked, neither Windows nor
Linux nor Solaris required users to read the ACPI 2.0 spec to get their
comms ports working. Having the flexibility to do what you describe
above would be nice, but allowing mortal users to get their hardware
working would be ever nicer.
Scott
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
