wait_on_irq, CPU 0
irq 2[0,2]
bh 2[0,0]
<[c0109ca1]> <[c0109bde]>....
c0109ca1 <__global_cli+bd/14c>
c0109bde <synchronize_irq+e/14>
c0109ed1 <disable_irq+61/68>
c015ed4d <qdisc_restart+39/6c>
c015aa43 <dev_queue_xmit+3b/c8>
c0164719 <ip_output+85/b8>
c016521a <ip_build_xmit+29a/2cc>
alt-sysreq-p c01d0094 <__udelay+0/54>
alt-sysreq-B or PWR cycle is the only way out! arrrggg
System details available on request, reproducible if
someone wants to try a patch.
Reverted to 2.2.3 uP kernel for now
Martin
vanl@lucent.com
> Hello, world!
>
> There's a scary problem with the newer kernels (tried 2.2.3 and 2.2.6) and
> flood ping. I was able to kill my computer with the following (as root):
> # (ping -f somehost) & (ping -f otherhost) &
> I would consider this as a serious bug.
>
> 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.
>
> Nothing in the logs, either. A solitary `ping -f' seems to work okay (but
> didn't under 2.2.3, IIRC), but I only tried for a minute or so.
>
> This is on a 2xPII with 3c509 and IPv4. The 3c509 is compiled as a module,
> and there were no other modules loaded. My .config is available upon
> request. ping version is from Debian (potato) netbase 3.12-2. If I left
> out something relevant please be so kind and tell me.
>
> The machine (and network) in question are mine and I can try patches or
> provide more info.
>
> 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/