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

[danny () CHATSYSTEMS COM (danny)]

Greetings,
We have had simular problems with 3c905b on a linux2.2.x box. Its a heavly
used box handling a lot of packets (IRC server + WWW server). The host
randomly locks up. If we catch it promptly (within a minute or so) we can
config down/up the interface and its fine. Otherwise it begans screaming about
being out of memory and or completely freezes up.  We've been trying to figure
this out for a few months now.   We tried using a different driver, but
machine didnt agree with the alternate driver at all.

 You might contact the appropriate linux mailing lists about it and see
what they can tell you.  If you do happen to get a solution to this, we
would be greatful to hear about it.

        Danny Mitchell, Internet Chat Systems, Inc.

Bill Paul was known to have stated:
> 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."
> =============================================================================


--
--------------------=================================--------------------------
              DannyM  -- http://www.wildstar.net/~danny
        http://www.chatsystems.com -=- http://www.wildstar.net
             WWW IRC and TELNET Chatrooms and Chat Servers
--------------------=================================--------------------------
Everything that I post is of my personal opinion, and not that of my employer!