Re: [cobalt-users] kernel: eth0: Too much work at interrupt

[flash22@xxxxxxx]

On Thu, 23 Aug 2001, fjc wrote:

> Cobalt Support rambled on meaninglessly....[sic]
> > Its the switch that your RaQ is plugged into.

> Under what circumstance will a Raq3 running build 2.2.14C10 generate the
> kernel error stated below, and then shutdown eth0? And what if anything can
> be done to prevent it?
> 
> I'm suspicious of broadcast storms since we have a good-sized layer two
> environment, but just the same, only the Raq is gagging.

Your suspiscoun is plausable, the other possability is some worm or such
put the card into promiscous mode, burying it n packet data that the
kernel can't pooosbly handle at that speed...

> > > kernel: eth0: Too much work at interrupt, status=0x4050.

The problem is , this message isn't as helpfull as one would hope, it
basicly means the kernel was still talking to the card when the card
interrupted it again , probably with more data, but it could also be that
a higher priority device used up all the available time(eg the disk) and
starved the network handler...or it could be a flaky network card
generating bogus interrupts sporadicly....

Assuming it's due to overruns, you are looking for low level stuff that
happens below the tcp stack, so broadcast/arp/certain ICMP stuff is about
all that's important...everything else will cause overruns outside the
interrupt handler , and different errors (if any)

What do you get for statistics from ifconfig? eg, packets lost,errored
etc? and is the card promicsous? in broadcast mode for interfaces it
shouldn't be ? multicast? (on a full duplex card, you shouldn't see
collisions btw)

A packet dumper might be interesting also, SYN floods from some local
machine on the network with a lame worm can cause havoc as well...(The
kernel kack that tries to diffuse SYN floods also consumes a bit of
resources timewise)

gsh