>I did look at the source. Though you are correct that the find function
>could be pickier, my whole point was that, now that we have bus_space
>mappings, _if_ we look for ne1 & ed2 before mcd, and we find one of the
>two, we won't match the mcd. 

You report that your system hung when mcd was in the GENERIC config.
At that point, the mcd driver didn't do <bus.h> and may not even have
done port accounting.  (The port accounting obviously makes a huge
difference).

When did you see these total system hangs, exactly (what date of
-current?)

>Line 871, in mcdprobe, tries to map in the
>I/O region first. If a network card were matched first, that'd fail.

Yes, I agree that it would.

>Note: I'm implicitly assuming isasearch & isascan stay as-is & attach a
>driver immediatly after its probe succedes.


>For my system, changing the order of probes is NOT a kludge, it is a
>necessity. 

Bill, we're talking past each other. If there are *still* problems
like the one you describe, then it's due to a bug in the relevant
probe routines. Changing the probe order does not fix that bug, it
merely hides it.  Whereas the NetBSD philosophy is to *fix* the bug.
Simply changing the probe order is a kludge. It may well have been
necessary on your system in the past, but it was still a kludge.


>My experience with GENERIC kernels, back when they had mcd's in
>them, was that they FROZE my computer. Admittedly it's been about a year
>since I tried, and I don't remember if the mcd successfully probed or not.

If there was anything at the ports where mcd was configured, the mcd
driver would have attached itself there. If the mcd driver wasn't
doing port accounting, the ed driver may have subsequentl attached an
if_ed device at the same I/O ports. At that point *all* bets are off.
(I can't easily check the CVS logs right now.)


>If, however, I misremembered, and the mcd just happily sat on top of my
>network card w/ no other lossage (beyond no ftp access), then you're
>right. It's a bad probe and ordering the tests'd just be kludgy. But I
>honestly think there were seizures, and not by me. :-)

There may well have been seizures, if the mcd probe is ``too
invasive'', and the 8390 code doesn't reset the 8390 properly.  Or
there may be hangs due to both driver trying to talk to the same IO
ports.

I'd be willing to send patches to you to test after 1.3 is out, if
you're willing to try them. (it just means changing mcd_find() to
reject cards that don't return 'M', 'F' or 'D', adding mcd back to the
config file, and seeing if the resulting kernel works or not.)