[lkml]   [1999]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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 <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.054 / U:5.836 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site