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 ...

From: 韓家標 Bill Hacker <askbill_at_conducive.net>
Date: Tue, 16 Oct 2007 01:41:24 -0400
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 Hacker
Received 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