Messages in this thread | | | Date | Sun, 18 Apr 1999 12:23:37 +0300 (EEST) | From | Taneli Vahakangas <> | Subject | Re: The Deadly `ping -f' |
| |
Hello Greg, all,
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/
| |