Re: 2.1.127 reboots...

Jim Bauer (jfbauer@home.com)
Mon, 16 Nov 1998 00:46:46 -0500

In article <m0zf3d9-0007UGC@the-village.bc.nu> you write:
>> occuring between 2 hours and 22 hours, so it's still WAY too early too
>> tell if it really is the uniprocessor build. But something IS messed up.
>>
>> Any thoughts on any way we can isolate this animal better?
>
>The scheduler stuff by volume seems to be much smaller than the IRQ stuff.
>Does a very large amount of interrupts make it die rapidly (eg flood pinging
>it)

This is with 2.1.127 non-SMP compiled with gcc 2.7.2.3

I ping flodded the system (200MHz K6) from a P90 for 30 minutes
without an problems. It never even lost a packet. I also gernerated
outgoing ping-floods. That ran ok, but did consume all the CPU
time and through the interrupts and context switches to about 5000-
6000 per second.

Now the unexpected part.

While the system was froze quite bad, I tried a ping flood. I got all
put 15% of 11031 packets. But the surprising part was that the ping
flood unfroze the system. That happened 3 different times. Once with
2.1.127 and twice with 2.1.128+arca19. I thought I imagined it the
first time. However, the ethernet driver (tulip, non-module) spit out the
following and stopped working till reboot.

eth0: 21041 transmit timed out, status fc660000, CSR12 000001c8, CSR13 ffffef05,
CSR14 ffffff3f, resetting...
eth0: 21041 transmit timed out, status fc660010, CSR12 000052c8, CSR13 ffffef09,
CSR14 fffff7fd, resetting...
eth0: 21041 transmit timed out, status fc660000, CSR12 000001c8, CSR13 ffffef05,

-- 
Jim Bauer, jfbauer@home.com


-
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/