OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq Archives: Flaw in 3c59x.c or in Kernel?

Flaw in 3c59x.c or in Kernel?

Subject: Flaw in 3c59x.c or in Kernel?
From: Sonny Parlin (parlinSTARBURSTSOFTWARE.COM)
Date: Tue Jan 04 2000 - 08:21:36 CST

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).

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-----------

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. Has anyone else seen this?? Any solutions?? Is this a driver
problem or a kernel problem
or what?? I can post the source code to the app used to freeze the Linux
machine, but it's just a simple
udp receiver that reads from the socket and writes to disk...

-Sonny

This archive was generated by hypermail 2b27 : Tue Jan 04 2000 - 14:54:29 CST