[vortex] 3c59x "just stops"

Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de
Wed, 18 Apr 2001 14:39:05 +0200 (CEST)


On Wed, 18 Apr 2001, Scott A. McIntyre wrote:

> Yes, SMP, good suggestion on the no apic; will try that.

AFAIK, only 2.4 has (or had) the problems with lost interrupts on SMP
systems. If 2.2 had the same problems, there might be something else. The
suggestion with "noapic" applies to 2.2 as well (if you still want to try
2.2).

> Anywhere from days to weeks.  The most is about two weeks.  This
> suggested to me that it was somehow tied to the number of Rx'd patckets.

After reading the rest of the message, my guess is that it's not related
to number of Rx packets, but to pps (packets per second).

> It will regularly complain about:
> kernel: eth1: Too much work in interrupt, status e401.

That normally means that you receive very many packets in a short time...

The problem migth be like this: the driver is exceeding number of
iterations through the interrupt routine and issues this message, then
disables the interrupt and waits for a timer to wake it. Then something
wrong is happening with this timer (similar to other SMP problems with
lost interrupts), so that the driver's interrupt is never re-enabled. Then
the card fills up the Rx ring and goes in an UpStall state (where no
packet is received) - I guess this explains why the card is no longer
flashing the LED.

Depending on what you do with the computer, it might worth increasing the
"max_interrupt_work" value, which determines the maximum number of
iterations through the interrupt routine, to try to eliminate the
exceeding situation. However, this means that the CPU might spend more
time inside the interrupt routine of this driver, processing packets; IOW,
you give more "priority" to receiving packets through this interface than
to other activities on the computer. If you have a fast enough CPU and
it's not loaded by other activities (including traffic on other NICs),
increasing "max_interrupt_work" to 64 or 100 might give good results.
You can modify this value by either modifying and recompiling the driver
or by passing it as a module option.

Sincerely,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De