lkml.org 
[lkml]   [1997]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Problems with Acction Link series fast ethercombo-tx pci adapter
Date
> During installation of a software router with three 100 mbit adapters, we
> got some problems. We are getting the following error:
>
> eth0: Too much work at interrupt, csr5=0xfc668000.
>
> Each time the message appears, the transfer seem to halt for a short time.
>
> The adapter is based on digital 21140-AC. We got a single card based on
> digital 21140-AB that works without any problems.
>
> We use kernel 2.0.27. We tried to use tulip.c from 2.1.20 but it does not
> fix the problem.

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.

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