M. Warner Losh wrote: > iIn message: <20071015234251.GR39759_at_funkthat.com> > John-Mark Gurney <gurney_j_at_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 HackerReceived on Tue Oct 16 2007 - 03:41:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC