The message is not really an error in itself. In all of his drivers,
Donald has tried to be fair to the rest of the kernel, and thus set
a reasonable (but arbitrary) limit on the number of times the core of
the interrupt handler will be run per physical hardware interrupt.
Most other OS drivers won't exit the IRQ handler until the card says
"Ok, no more packets to send/receive - you can go now." and so in
principle you can end up stuck in the IRQ handler for a *long* time
if there is a continuous stream of 100Mbps of traffic being thrown at
the box.
Okay, the key to all of the above is the word "arbitrary". Which means
that if there isn't some real hardware problem, and the above is just
due to you really driving the equipment flat out (check the bits in
csr5 to verify this), you can change this limit. To do so, go into the
file linux/drivers/net/tulip.c and near about line 900 you will see
"boguscnt=10" which is the limit on the number of passes mentioned above.
Ten is probably appropriate for an ISA card on a 486, but ten passes on
a fast machine with a decent bus bandwidth probably doesn't translate
into spending a lot of time in the IRQ handler, and hence may be overly
restrictive when you really start working the card heavily. Try
increasing it to 20 or even 50 and things should be okay.
Or if you are a bit of a hacker, replace the limit with a "high water
mark" to see just how high the number of passes gets while the box
is heavily loaded. Something like:
int boguscnt=0;
static int higwater=5; /* Should hit this soon under load. */
...
[handle interrupt]
...
boguscnt++;
if (boguscnt>highwater) {
printk("%s: New max level reached: %d passes\n", dev->name, boguscnt);
highwater = boguscnt;
}
will tell you how high a limit you hit when thrashing the machine really
hard with network activity. Hope this helps.
Paul.