Subject: Re: wt driver conflict with ????
To: Tim Rightnour <root@garbled.net>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-i386
Date: 06/23/1998 12:10:38
Tim Rightnour <root@garbled.net> writes:

># When the mcd driver didnt have port accounting and had an overly-keen
># match routine, sure, it was busted. But after the above, I see no
># cause for especial concern, certainly not for SMC cards.
># Am I missing something?

>This really scares the crap outta me.. 

Understood.  I guess the acid test is to _try_ it.  Do you still have
the maths needed to fix a hosed card?  If you send me a config I can
build a kernel, if you're willing to try it. Or I can build a GENERIC
kernel with mcd and put it up for ftp.


> The point is..  it is different from the one you have, and as far
>as I know, this version was the only one that graciously allowed itself to be
>reporgrammed.  Along with the ultra.. though I am not sure about that one.)

I think mine's an Ultra, but Im honestly not sure.  I can check later
(its in a wiring closet).


>I'll be totally honest.. I don't remeber what was wiping my card out.. but I
>think it was the mcd driver..  But it *really* drove me nuts.  I avoided 1.1
>and 1.2 for the longest time because of this, and upgraded alot of machines
>from 1.0 to 1.3 directly.


>All I can say is.. if we re-enable that driver.. we had better be sure we
>aren't screwing anybody's hardware up this time.. 

OK.  But I buy Charles' explanation (he's ususally right about such
things), which says it's the "el" driver which set the card into a
not-really-there state and "wt" driver that *really* scrooed things up
by writing that state back to the EEPROM.

Since the wt driver is now at 0x308, that particular nastiness just
can't happen anymore.]

One thing I haven't got feedback on is changing the probe order,
making the mcd and wt devies probes the very last true ISA devices to
be probed.  That should make them marginally safer.  but if either one
is writing back "bad" values from earlier probes, leaving them where
they are would be better.

One more idea: if the "el" driver was (part of) the problem, why don't
we change it so it reads and saves the two bytes it writes to, and
then restores their values if the probe fails?