From owner-freebsd-current@FreeBSD.ORG Tue Oct 16 05:41:30 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8E9F16A417 for ; Tue, 16 Oct 2007 05:41:30 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from conducive.net (conducive.net [203.194.153.81]) by mx1.freebsd.org (Postfix) with ESMTP id 879EB13C468 for ; Tue, 16 Oct 2007 05:41:30 +0000 (UTC) (envelope-from askbill@conducive.net) Received: from cm218-253-81-177.hkcable.com.hk ([218.253.81.177]:65061 helo=pb.local) by conducive.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1IhfBE-0005JR-A0 for freebsd-current@freebsd.org; Tue, 16 Oct 2007 05:41:24 +0000 Message-ID: <47144F04.6000703@conducive.net> Date: Tue, 16 Oct 2007 01:41:24 -0400 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20070930114914.GB38896@alchemy.franken.de> <47001D02.4080700@protected-networks.net> <20071015234251.GR39759@funkthat.com> <20071015.225537.43008411.imp@bsdimp.com> In-Reply-To: <20071015.225537.43008411.imp@bsdimp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: [cvs commit: src UPDATING src/share/man/man4 pci.4 src/share/man/man9 pci.9 src/sys/amd64/include legacyvar.h src/sys/amd64/amd64 legacy.c src/sys/amd64/pci pci_bus.c src/sys/arm/xscale/i80321 i80321_pci.c src/sys/arm/xscale/ixp425 ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 05:41:30 -0000 M. Warner Losh wrote: > iIn message: <20071015234251.GR39759@funkthat.com> > John-Mark Gurney writes: > : Michael Butler wrote this message on Sun, Sep 30, 2007 at 18:02 -0400: > : > Marius Strobl wrote: > : > > As mentioned in UPDATING the change below requires the hal port > : > > to be recompiled in order to continue to work. On !386 you > : > > additionally need to update to xorg-server-1.4_1,1. > : > > Regarding common ports affected by the introduction of support > : > > for PCI domains these two ports should be it. > : > > Other consumers of potentially also need to be > : > > recompiled and adjusted, f.e. sjog needs to be recompiled but > : > > should need no changes. Generally, if a port uses pc_bus it > : > > also needs to deal with pc_domain now. > : > > : > This breaks [ls|set]pci even when recompiled. > : > > : > It also breaks my ability to use an /etc/rc.early containing .. > : > > : > pciconf -wb pci0:30:0 0x1a 8 > : > > : > .. which is required to allow any cardbus devices, e.g. Netgear WG511T, > : > to work. The problem is that we don't (and nor does the BIOS) properly > : > set the subordinate bus of the parent PCI-PCI bridge and the above > : > command sets it 'manually'. > : > : Is there a PR for this? Could you send a verbose boot message for this? > : It shouldn't be hard to fix, and pretty easy one to fix too. > > This is actually getting quite common these days. We need to fix it > in the bus layer, but although I've scoped out the work, I've not had > the time to execute. There's two ways to accomplish this. One is to > go to a multi-pass newbus probe/attach. The other is to just walk the > entire tree of each pci domain numbering the busses. We also need to > do this for resources as well... > > Warner > _______________________________________________ Given the rapid, and accelerating rate of change in bus, bridge & other I/O silicon, firmware, and what is attached/not, it is likely to get worse - far worse - before it gets better. IMHO this whole area needs to be as 'adaptable' as can be - revealing info about hardware - real, logcal, or virtual - even if things that use that info haven't fully caught up. dmesg.boot & many friends on steroids wouldn't add a lot of delay to booting, nor log storage, but might help speed accurate response to 'progress'. so --- can *both* of the above approaches co-exist? Either as optionable, auto-fallback, or 'run both, compare & report diffs'? Yes, the code is more complex. But might that be leveraged into reduced complexity in a great deal more code? Bill Hacker