[13270] in bugtraq
Re: Flaw in 3c59x.c or in Kernel?
daemon@ATHENA.MIT.EDU (Pug Bainter)
Thu Jan 6 16:57:37 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000105142700.A6036@stardock.pug.net>
Date: Wed, 5 Jan 2000 14:27:00 -0600
Reply-To: Pug Bainter <pug@PUG.NET>
From: Pug Bainter <pug@PUG.NET>
X-To: David Malone <dwmalone@MATHS.TCD.IE>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20000105104253.A31162@walton.maths.tcd.ie>; from
dwmalone@MATHS.TCD.IE on Wed, Jan 05, 2000 at 10:42:53AM +0000
David Malone (dwmalone@MATHS.TCD.IE) said something that sounded like:
> > eth1: Too much work in interrupt, status e481. Temporarily disabling
> > functions(7b7e).
> We saw this with some Linux machines in college that were connected
> to busy 100Mb/s ethernet. Bill Paul is right when he says ifconfiging
> down and then up fixes the hang. To work around the problem we changed
> max_interrupt_work from 20 to 200 and I don't think they've seen any
> hangs since. (You can find this in the .c file for the driver).
From the source code, max_interrupt_work is a insmod-settable variable
since 3/8/97. I've never tried it admittedly, but will be shortly.
Ciao,
--
Richard "Pug" Bainter | AMD, Inc.
Senior System Engineer | Mail Stop 625
Richard.Bainter@amd.com | pug@pug.net | 5900 E. Ben White Blvd
Phone: (512) 602-0364 | Fax: (512) 602-6970 | Austin, TX 78741
Note: The views may not reflect my employers, or even my own for that matter.
