On Tue, 13 Apr 1999 12:33:44 -0700 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > Manuel's suggestions are fine. But there's also 69998, which may or
 > may not be what you're remembering. Jason's suggestion (in PR#6998) is
 > to add an splnet()/splx() pair in epshutdown().  That should fix this
 > particular problem.

Yes, this fix should be committed.  It occurs to me that some other
Ethernet drivers probably have this problem, too.

 > However, some 3Com elink3 cards _Just Dont Implement
 > S_COMMAND_IN_PROGRESS after resets.  (The code says this loudly, in
 > ep_complete_command(), as does the CVS log).
 > 
 > Nevertheless, some foolish person added code to epinit() which
 > unconditionally recovers from errors by busy-looping until
 > S_COMMAND_IN_PROGRESS.  My guess is that something is causing an
 > interrupt during the shutdown hook which calls epshutdown().  that
 > interrupt indeed tries to access the card, gets a "failure", and then
 > calls epreset() which calls epinit(), which loops forever.
 > 
 > 
 > This same problem (the S_COMMAND_IN_PROGRESS loop, not the spl botch)
 > is also the root cause of of PR# kern/7067.

So, what you want to do is poll S_COMMAND_IN_PROGRESS and then bound the
loop to 1ms (plus whatever slop) to catch both families of chips.

It's also be nice to know why the 3c597 isn't raising LINK.

 > I wonder if a delay loop in epinit() isn't a better solution...

See above :-)

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>