From owner-freebsd-stable@FreeBSD.ORG Mon Oct 31 18:34:08 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 CCE5B16A41F for ; Mon, 31 Oct 2005 18:34:08 +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 1ADBF43D45 for ; Mon, 31 Oct 2005 18:34:08 +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 j9VIXBeb006066; Mon, 31 Oct 2005 11:33:11 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 31 Oct 2005 11:33:11 -0700 (MST) Message-Id: <20051031.113311.104037760.imp@bsdimp.com> To: scottl@samsco.org From: Warner Losh In-Reply-To: <43665788.4070807@samsco.org> References: <20051031160150.GB87483@stack.nl> <20051031.103408.71093019.imp@bsdimp.com> <43665788.4070807@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 11:33:13 -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 18:34:09 -0000 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