-----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
kbottner@istation.com
- -----Original Message-----
From: owner-linux-kernel@vger.rutgers.edu
[mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of William R.
Lorenz
Sent: Wednesday, January 05, 2000 11:04 AM
To: linux-kernel@vger.rutgers.edu
Subject: FW: Flaw in 3c59x.c or in Kernel?
- -----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ@SECURITYFOCUS.COM]
On Behalf Of Bill Paul
Sent: Friday, July 10, 2893 6:44 PM
To: BUGTRAQ@SECURITYFOCUS.COM
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: 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."
======================================================================
=====
=
- -
To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST