On Tue, 21 Oct 1997, Jonathan Stone wrote:

> 
> On Tue, 21 Oct 1997, Bill Studenmund wrote:
> 
> >Is there any way to get config to order device tests other than
> >re-aranging the config files? 
> 
> ``No''.
> 
> > Because if the ne2000, and probably the ed
> >driver, could get included (and thus probed) before the mcd and wt drivers
> >do, now that we have the bus-space allocation, we could probably turn them
> >back on in the GENERIC configuration.
> 
> >The problem is that the ne2000 and ed drivers are defined in
> >/sys/conf/files which is read after /sys/arch/i386/conf/files.i386 (which
> >includes /sys/dev/isa/files.isa which has these two drivers in it).
> 
> Bill, this turns out not to be the case.
> 
> Check out mcd_find() around like 853.
> 
> Notice that the mcd driver wil seize ports and attach an mcd device if
> there is _anything_ present at the ports that it probes.  That is so
> broken it's braindamaged. If your machine has a network card at those
> I/O addresses, the MCD driver has already grabbed those ports and
> won't give them back.  (We have source: why not UTSL before making claims?)

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. Line 871, in mcdprobe, tries to map in the
I/O region first. If a network card were matched first, that'd fail.

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

> Early this year (April, IIRC) I suggested to Perry that we change the
> MCD driver so that, by default, mcd_find() only accepts cards that
> return 'M' (M_itsui), 'F' (F_x001") or D (F_X001D), and add the fixed
> mcd to the standard GENERIC config file.  I suggested this
> specifically for people who might want to install 1.3 from CD and who
> are stuck with an mcd cd.  I still think that's the `right' thing to
> do -- (we could add debug code and add other codes for MCD-compatible
> hardware as they become known) -- but that idea was rejected long
> before the 1.3 release cycle started.

Changing the probe sounds like it'd be a good thing.

> Putting the mcd probe after other probes cannot hurt, and would help
> most configurations, but it's still a kludge for broken probe routine.
> The right thing to do is to fix the mcd probe if we possibly can.
> (Maybe we *cannot* do a good probe for this device; I honestly don't know.)
> But it's almost without question too late to do either for 1.3.

For my system, changing the order of probes is NOT a kludge, it is a
necessity. 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.

This week I ran into a similar problem with the lc0 driver. It tries all
possable card locations. The FIRST time it tries to read what would be the
rom in a lemax_isa card (0x315), the computer freezes (PR kern/4308). So
it seems to me that the ne2000 card does NOT like random pokes & peeks. 
Any probe routine touching it might make it sick. 

>From reading driver comments, I _think_ reading the device at off times
triggers a DMA read when there's no data, locking the machine.

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

Take care,

Bill