On Sat, 17 Apr 1999, Greg Zornetzer wrote:
> On Sun, 18 Apr 1999, Taneli Vahakangas wrote:
> > The machine fell into the ever-interesting land of __delay, __udelay and
> > __global_cli (as witnessed with SysRq-P), and was not able to respond
> > outside pings. Unfortunately, SysRq-U (or -S) didn't work.
> I tried to reproduce this quickly on my machine: Uniprocessor with 3c509
> compiled into the kernel. I ran a flood ping (using Alexy Kuznetsov's
> fixed ping program) from my machine to 2 other machines on a personal lan,
> as well as a flood ping to the machine's own ethernet address, and a flood
> ping on loopback. The machine was totally stable (if a bit slow) - it's a
> P66.
>
> Anyway, maybe the problem is some SMP locking issue not present on UP.
> Could you try recompiling the kernel uniprocessor and run the exact same
> test (just be careful you remake all of the modules uniprocessor).
Yes, it is SMP indeed. A UP kernel+modules works allright, using either
3c509 or eexpress. A SMP kernel fails with both. The eexpress driver is
more interesting, though, it spits out these:
eth0: tx interrupt but no status
while doing "The Double Flood Ping" and afterwards all networking is
wedged, it only says:
eth0: i82586 reset timed out, kicking (5 times in a row)
eth0: i82586 not responding, giving up.
Then I said
# ifconfig down
# ifconfig up
and the machine locked up again. But as I said, UP kernel works pretty
well -- although it says "tx interrupt but no status" during ping -f, it
doesn't crash the machine.
Taneli <taneli@firmament.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/