Date: Tue, 16 Oct 2007 01:41:24 -0400 From: =?UTF-8?B?6Z+T5a625qiZIEJpbGwgSGFja2Vy?= <askbill@conducive.net> To: freebsd-current@freebsd.org 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 ... Message-ID: <47144F04.6000703@conducive.net> In-Reply-To: <20071015.225537.43008411.imp@bsdimp.com> References: <20070930114914.GB38896@alchemy.franken.de> <47001D02.4080700@protected-networks.net> <20071015234251.GR39759@funkthat.com> <20071015.225537.43008411.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > iIn message: <20071015234251.GR39759@funkthat.com> > John-Mark Gurney <gurney_j@resnet.uoregon.edu> 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 <sys/pciio.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47144F04.6000703>