Messages in this thread | | | From | Paul Gortmaker <> | Subject | Re: Problems with Acction Link series fast ethercombo-tx pci adapter | Date | Sun, 19 Jan 1997 17:49:29 +1000 (EST) |
| |
> 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.
| |