Bugtraq mailing list archives
Re: Flaw in 3c59x.c or in Kernel?
From: danny () CHATSYSTEMS COM (danny)
Date: Tue, 4 Jan 2000 21:17:57 -0600
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!
Current thread:
- Flaw in 3c59x.c or in Kernel? Sonny Parlin (Jan 04)
- Re: Flaw in 3c59x.c or in Kernel? Raymond Dijkxhoorn (Jan 04)
- Re: Flaw in 3c59x.c or in Kernel? Bill Paul (Jan 04)
- Re: Flaw in 3c59x.c or in Kernel? danny (Jan 04)
- userhelper/PAM exploit Derek Callaway (Jan 04)
- Re: Flaw in 3c59x.c or in Kernel? Raymond Dijkxhoorn (Jan 05)
- Re: Flaw in 3c59x.c or in Kernel? David Malone (Jan 05)
- Re: Flaw in 3c59x.c or in Kernel? Sonny Parlin (Jan 05)
- Re: Flaw in 3c59x.c or in Kernel? Jonathan Poole (Jan 05)
- Re: Flaw in 3c59x.c or in Kernel? Pug Bainter (Jan 05)
- Re: Flaw in 3c59x.c or in Kernel? Sonny Parlin (Jan 05)
- <Possible follow-ups>
- FW: Flaw in 3c59x.c or in Kernel? William R. Lorenz (Jan 05)