-----Original Message----- From: owner-linux-kernelat_private On Behalf Of Keith Bottner Sent: Wednesday, January 05, 2000 12:11 PM To: Bill Lorenz; linux-kernelat_private Subject: RE: Flaw in 3c59x.c or in Kernel? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 3COM has new Linux driver source for 905B and 905C cards on their website. This allows the cards to run at their full potential and with a great level of stability. I suggest downloading the new driver code, it works a whole lot better and a lot of the 905B and 905C weirdness with the old 3c59x driver is eliminated. Keith Bottner kbottnerat_private - -----Original Message----- From: owner-linux-kernelat_private [mailto:owner-linux-kernelat_private]On Behalf Of William R. Lorenz Sent: Wednesday, January 05, 2000 11:04 AM To: linux-kernelat_private Subject: FW: Flaw in 3c59x.c or in Kernel? - -----Original Message----- From: Bugtraq List [mailto:BUGTRAQat_private] On Behalf Of Bill Paul Sent: Friday, July 10, 2893 6:44 PM To: BUGTRAQat_private Subject: Re: Flaw in 3c59x.c or in Kernel? 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: wpaulat_private | Department of Electrical Engineering Home: wpaulat_private | Columbia University, New York City ====================================================================== ===== = "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ====================================================================== ===== = - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomoat_private Please read the FAQ at http://www.tux.org/lkml/ -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com> iQA/AwUBOHN7HMqHs5kOeqcOEQJQqgCdEoVUR5hSzMZrsBmb/CixRGOSnaQAn20U box2W4E6LPyJlztXnzUdOCuh =jH54 -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:26:42 PDT