Date: Mon, 31 Oct 2005 12:48:49 -0700 (MST) From: Scott <scottl@pooker.samsco.org> To: Warner Losh <imp@bsdimp.com> Cc: marcolz@stack.nl, stable@freebsd.org Subject: Re: HEADS UP! 6.0-RELEASE coming Message-ID: <20051031124649.M19239@pooker.samsco.org> In-Reply-To: <20051031.113311.104037760.imp@bsdimp.com> References: <20051031160150.GB87483@stack.nl> <20051031.103408.71093019.imp@bsdimp.com> <43665788.4070807@samsco.org> <20051031.113311.104037760.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Oct 2005, Warner Losh wrote: > From: Scott Long <scottl@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051031124649.M19239>