HEADS UP! 6.0-RELEASE coming

[Scott]

On Mon, 31 Oct 2005, Warner Losh wrote:
> From: Scott Long <scottl at samsco.org>
> Subject: Re: HEADS UP! 6.0-RELEASE coming
> Date: Mon, 31 Oct 2005 10:42:32 -0700
>
>> 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.
>
> I didn't need to read the AML to get the serial ports working in the
> above example.  devinfo -v gave me all I needed to know, a command
> that's very accessible to mere mortals, as you put it.
>
> The issue with other boards that I've seen is that you have things
> like PORTA and PORTB which are listed in COM2 and then COM1 resource
> order.  I could have sworn that the AML that you'd posted a while ago
> was a mirror of this.  I'd be happy to take a look at the AML of the
> system you are having trouble with to confirm this.
>
> There is a secondary issue to this as well.  That is that some com
> ports can be assigned to one of many different addresses.  That also
> needs to be addressed, but so far appears to be fairly uncommon.
>
> Warner
>

  I guess I'm missing the jump between running devinfo and knowing how to 
parse and manipulate ASL/AML.

Scott