Re: Flaw in 3c59x.c or in Kernel?

[wpaul () CTR COLUMBIA EDU (Bill Paul)]

Of all the gin joints in all the towns in all the world, Sonny Parlin had
to walk into mine and say:

> I sent this once, but it never made it through, here is try number two...
>
> Using a home grown client/server app, I have been able to easily crash
> Linux. The application is a
> simple udp sender/receiver. The udp receiver runs on a Linux machine with a
> 3c905b Ethernet
> card which uses the latest version of the 3c59x.o module (v0.99L), and the
> kernel is 2.2.12-20. By sending the Linux machine a 100MB file as fast as
> the sender can send it on a 100Mbps network, the Linux machine responds by
> freezing up completely with a console message that states:
>
> eth1: Too much work in interrupt, status e481. Temporarily disabling
> functions(7b7e).

This status value comes from the interrupt/status register. It means:

- 0x0001 -- interrupt latch (the NIC really did signal an interrupt)
- 0x0080 -- statistics overflow (reading a statistics counter register
            zeros it out: if one of the stats registers reaches its
            max value point before the driver has a chance to read it,
            you get an interrupt telling you it overflowed)
- 0x0400 -- DMA upload complete -- a packet was received and DMA'ed to
            the host
- 0xE000 -- doesn't mean anything (these bits are unused)

> Unfortunately, temporarily seems to mean "forever"...
>
> Here is a snip from 3c59x.c:
>
> ---------snip-----------
>               if (--work_done < 0) {
>                       if ((status & (0x7fe - (UpComplete | DownComplete))) == 0) {
>                               /* Just ack these and return. */
>                               outw(AckIntr | UpComplete | DownComplete, ioaddr + EL3_CMD);
>                       } else {
>                               printk(KERN_WARNING "%s: Too much work in interrupt, status "
>                                          "%4.4x.  Temporarily disabling functions (%4.4x).\n",
>                                          dev->name, status, SetStatusEnb | ((~status) & 0x7FE));
>                               /* Disable all pending interrupts. */
>                               outw(SetStatusEnb | ((~status) & 0x7FE), ioaddr + EL3_CMD);
>                               outw(AckIntr | 0x7FF, ioaddr + EL3_CMD);
>                               /* The timer will reenable interrupts. */
>                               break;
>                       }
>               }
> ---------snip-----------

It looks like the vortex_timer() routine "reenables" interrupts by
calling enable_irq() at exit (it calls disable_irq() at entry). I think
disable_irq() just prevents Linux from calling the driver's interrupt
routine, and enable_irq() undoes this effect: this is *not* the same thing
as telling the chip to start sending interrupts again. The interrupt
handler seems to be assuming that the timer routine will reprogram the
chip, but it doesn't. (At least, not as far as I can tell.)

> Notice the comment that says "Timer will reenable interrupts".... That's not
> happening, my testing has
> been on two separate machines with the same kernel/card/driver and neither
> machine ever comes
> back to life.

Using ifconfig to bring the interface down and then back up again should
cause the driver to re-init the card and re-enable interrupts. If this
makes the interface work again, then the vortex_timer() routine may indeed
be doing the wrong thing.

> Has anyone else seen this??

No, but I use FreeBSD. :)

> Any solutions??

Go to the vortex_timer() routine, and right after the enable_irq();
statement near the end, try adding the following two likes:

                outw(vp->status_enable, ioaddr + EL3_CMD);
                outw(vp->intr_enable, ioaddr + EL3_CMD);

This should tell the chip to start generating interrupts again.

> Is this a driver
> problem or a kernel problem
> or what??

It looks like it could be a driver problem, however I could be wrong.
If re-enabling the interrupts like I suggested makes it go away, then
you'll know for sure. If this turns out to be the case, you'll want to
send a bug report to Donald Becker.

-Bill

--
=============================================================================
-Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
Work:         wpaul () ctr columbia edu | Department of Electrical Engineering
Home:  wpaul () skynet ctr columbia edu | Columbia University, New York City
=============================================================================
"Mulder, toads just fell from the sky!" "I guess their parachutes didn't open."
=============================================================================