Flaw in 3c59x.c or in Kernel?

[Sonny Parlin <parlin@STARBURSTSOFTWARE.COM>]

    [ The following text is in the "iso-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

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