In message <877lrisdax.fsf@jekyll.piermont.com>,
   "Perry E. Metzger" writes:

>
>I distinctly remember other people running into this particular issue
>before and in fact diagnosing the bug but no one did anything about it 
>-- check the mail archives for tech-net, port-i386 and
>current-users...
>
>Perry

Perry, 

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.

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.


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

[Manuel, Martin: can you test patches if I send them to you? Anyone else?]



>Manuel Bouyer <bouyer@antioche.lip6.fr> writes:
>
>> [Summary: on a system with a 3c509B and pciide, at reboot, after the
>> 'syncing disks' message, we get 'ep1: adapter failure (ffff)' and the system
>> hang. This doesn't happen if we use wdc instead of pciide. Mason reported th
>is
>> first on 1.4_alpla, I've been able to reproduce it on a 1.3.3 system + pciid
>e
>> patches].
>> 
>> Wee, I got it on my system too. Unfortunably I can't do much hacking on
>> it, it's our router (rigth now it possible because there's nobody else here,
>> but I guess I'm going to sleep soon :).
>> I tried a few thing: 'ifconfig ep1 down', changing the irq of the board from
>> 7 to 5, without luck.
>> This message is from epintr(), and I really don't know why it's getting
>> such a bogus interrupt at this stage.
>> I wonder if this can't happen when we run the shutdown hook
>> epshutdown() (in elink3.c). It resets the board. At this point, if it
>> gets an irq I guess registers will not be available. I wonder if it should
>> run this a splhigh(), or call epdisable() between epstop() and
>> ep_complete_cmd() in epshutdown().
>> Could you try a few things here ? printf's in epshutdown() to track what he'
>s
>> doing, add a 'int s = splhigth()' at the begining of epshutdown() and 'splx(
>s)'
>> at the end, and call 'epdisable(sc)' between epstop() and ep_complete_cmd().
>> 
>> Now it's time to go to bed :)
>> 
>> --
>> Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
>> --