Hi,

[stuff about not probing at I/O addresses, where other devices
have been detected before deleted]

> Those were my thoughts, but, unfortunately, Greg came up with some
> boxes that couldn't find the npx, and whose mcd or some other device
> wasn't probed correctly.  It was all a bit nasty, and so I recommended
> that my patch be discarded.

Hmm, but isn't this the right direction to go? What keeps the npx
probe code from working if it can't probe on an I/O space that
is occupied by another device? If there is anything, then I'd call
the probe code for the npx broken, but maybe I am too naive?!

Let me outline it again, just to make things clear.

If a probe positively identifies a device at a certain I/O space,
then this I/O space is reserved for this device, right?

That means to me, that no other device can live there, so there
is no need to probe for another device at this location.

Now you can say, that the first probe code falsely identified the
device at this location and thus keeps other probe code from
testing this location. My answer to this is, that the probe
code for the first device needs to be fixed.

I know that the PC-architecture is quite broken. So tell me,
what design flaw in the PC architecture keeps this fairly simple
detection scheme from working? Or is it just, that noone has had
the time to fix all the probing routines?

  Guenther

P.S.: Note that I am trying to install NetBSD-1.1 on my i486
at home and I am partly struggling with probing issues as well:
I have an AIC6360 base hostadapter, and there is code in
aic6360.c which checks if the card is on the right interrupt,
but this code is obviously commented out with 
#ifdef NEWCONFIG, which I though port-i386 was using...
I will have a closer look into this, once I get NetBSD-1.1
installed on my machine (hopefully in a couple of hours,
but you never know ... )