From owner-freebsd-stable@FreeBSD.ORG Mon Oct 31 20:22:27 2005 Return-Path: X-Original-To: stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4961A16A421 for ; Mon, 31 Oct 2005 20:22:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCAFD43D46 for ; Mon, 31 Oct 2005 20:22:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9VKKIFK007274; Mon, 31 Oct 2005 13:20:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 31 Oct 2005 13:20:18 -0700 (MST) Message-Id: <20051031.132018.112620008.imp@bsdimp.com> To: scottl@pooker.samsco.org From: Warner Losh In-Reply-To: <20051031124649.M19239@pooker.samsco.org> References: <43665788.4070807@samsco.org> <20051031.113311.104037760.imp@bsdimp.com> <20051031124649.M19239@pooker.samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 31 Oct 2005 13:20:18 -0700 (MST) Cc: marcolz@stack.nl, stable@FreeBSD.ORG Subject: Re: HEADS UP! 6.0-RELEASE coming X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 20:22:27 -0000 From: Scott Subject: Re: HEADS UP! 6.0-RELEASE coming Date: Mon, 31 Oct 2005 12:48:49 -0700 (MST) > On Mon, 31 Oct 2005, Warner Losh wrote: > > From: Scott Long > > 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. You'd indicated that you'd prefer a method of specification that didn't require one understand ASL. With devinfo, one can get all the information one needs to create the location hints that I describe above w/o needing to know ASL, look at ASL, etc. Warner