To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 04/13/1999 12:33:44
In message <email@example.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
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
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 <firstname.lastname@example.org> 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
>> first on 1.4_alpla, I've been able to reproduce it on a 1.3.3 system + pciid
>> 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'
>> doing, add a 'int s = splhigth()' at the begining of epshutdown() and 'splx(
>> 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