[ i too quickly threw out the original message on this subject but... ]

> > What is a "bridge"?  What the heck is "prehistoric"/"miscellaneous"?
> > Why does it think it seems a phantom VGA device?  Is the "mass storage"/"IDE"
> > phantom the IDE ATAPI CD-ROM?

the classes you see ("prehistoric," "mass storage", "bridge") are what
the devices report as their device classes.  the subclasses
("miscellaneous," "IDE") are what they report as their subclasses.

there are several classes of devices (enumerated in dev/pci/pcireg.h,
or something like that; one of the PCI headers), including:

	"prehistoric"	(device done before class names were standardized)
	"mass storage"	(mass storage controllers, etc.)
	"video"		(I think that's the name...  video adapters, etc.)

i don't have your dmesg output anymore, but i'd guess that the
"bridge" you see (assuming it's the "prehistoric"/"miscellaneous"
device) is the PCI -> ISA/EISA bridge.  (If not, it's the device that
bridges the PCI and the CPU bus.

There are no phantom devices; the devices reported by the PCI code are
Really what's there.  The VGA device _is_ your VGA device (it's a PCI
VGA, right?).  the "mass storage"/"IDE" devices _is_ your PCI (E?)IDE
controller (it's a PCI controller, right?).


The PCI code is correct in telling you what's in your system.  the isa
code isn't.  in particular, what should happen is:
	(1) a global map of allocated addresses should be kept, so
		that two devices can't live in the same place
		(this would require that the pms port brokenness
		be fixed, but that's another story),
	(2) busses should be probed correctly, in particular:
		(a) PCI and/or EISA busses should be probed/attached
			first, IFF they exist in the system,
		(b) ISA should be probed second.
	(3) devices, when attached, should mark regions of
		I/O and memory space as being used,
	(4) other devices which use that I/O and/or memory space
		shouldn't be successfully probed, since the space
		is already in use.

The current ISA/EISA/PCI code as used in the i386 port is horribly
broken; the above brokenness is just one example.  (Another is the use
of special 'indirect' config flags when autoconfiguring ISA devices.
Why is this broken?  (1) It makes drivers _much_ harder to share
between ISA and other busses, and (2) it's not necessary (BSD/OS,
which also uses the LBL config program doesn't need to do it, for
instance...)


chris