Bug 16214

Summary: Driver for Intel EtherExpress 16 is unreliable, (if_ie.c)
Product: Base System Reporter: fitz <fitz>
Component: i386Assignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description fitz 2000-01-20 02:10:02 UTC
if_ie.c driving an Intel EtherExpress 16 causes machine to hang when network traffic is heavy.

Fix: 

http://www.jfitz.com/tips/freebsd_etherexpress16.html
How-To-Repeat: Heavy network traffic on an Intel Etherexpress 16.
Comment 1 Garrett A. Wollman 2000-01-20 02:54:00 UTC
<<On Wed, 19 Jan 2000 18:02:04 -0800 (PST), fitz@jfitz.com said:

>> Synopsis:       Driver for Intel EtherExpress 16 is unreliable, (if_ie.c)

Driver for Intel EtherExpress 16 is piece of crap.  (I can say that
because I wrote it.  It was my first device driver.)

Intel EtherExpress16 is also piece of crap.  Be nice to yourself and
buy a $5 NE2000 clone....

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
Comment 2 fitz 2000-01-20 03:21:53 UTC
Both driver and board are doing fine - see the (2 line) fix at
http://www.jfitz.com/tips/freebsd_etherexpress16.html

I'm still not 100% sure why the delay I added fixes the problem - I'm
guessing its related to incoming interrupts while the driver is attempting
to disable them. I wasn't about to start dissecting ancient spec sheets to
try and figure it all out. I'd also suspect that similar problems I've seen
reported with linux drivers can be fixed in the same way.

BTW, I got my 2 EtherExpress cards for $1 each, so I guess I'm up about $8
on hardware :-) Unfortunately, I'm probably down a few hundred $$'s if I
count the time I spent looking at the problem :-(
Fitz.

----- Original Message -----
From: "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>
To: <fitz@jfitz.com>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
Sent: Wednesday, January 19, 2000 6:54 PM
Subject: i386/16214: Driver for Intel EtherExpress 16 is unreliable,
(if_ie.c)


> <<On Wed, 19 Jan 2000 18:02:04 -0800 (PST), fitz@jfitz.com said:
>
> >> Synopsis:       Driver for Intel EtherExpress 16 is unreliable,
(if_ie.c)
>
> Driver for Intel EtherExpress 16 is piece of crap.  (I can say that
> because I wrote it.  It was my first device driver.)
>
> Intel EtherExpress16 is also piece of crap.  Be nice to yourself and
> buy a $5 NE2000 clone....
>
> -GAWollman
>
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the
same
> wollman@lcs.mit.edu  | O Siem / The fires of freedom
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad
Irschick
>
Comment 3 tedm 2000-03-10 08:03:52 UTC
Hi All,

What follows is a patch file of the driver that is created from the
modified driver source posted to the URL listed above.  This is posted
to help this PR conform with how PR's are requested to be filed.

*** /usr/src/sys/i386/isa/if_ie.c	Sun Aug 29 09:07:22 1999
--- if_ie.c	Thu Mar  9 23:29:55 2000
***************
*** 564,569 ****
--- 564,570 ----
  	struct	ie_softc *ie = (struct ie_softc *)sc;
  	int	unit = ie - &ie_softc[0];

+ 	return;
  	ee16_reset_586(unit);
  	outb(PORT + IEE16_ECTRL, IEE16_RESET_ASIC);
  	outb(PORT + IEE16_ECTRL, 0);
***************
*** 635,640 ****
--- 636,644 ----
  	bd_maddr = 0;
  	i = (ee16_read_eeprom(sc, 6) & 0x00ff) >> 3;
  	switch (i) {
+ 	case 0x01:
+ 		bd_maddr = 0xC8000;
+ 		break;
  	case 0x03:
  		bd_maddr = 0xCC000;
  		break;
***************
*** 648,653 ****
--- 652,658 ----
  		bd_maddr = 0xD8000;
  		break;
  	default:
+ 		printf("ie%d: unknown maddr id: %x\n", unit, i);
  		bd_maddr = 0;
  		break;
  	}
***************
*** 875,880 ****
--- 880,888 ----

  	/* Don't ack interrupts which we didn't receive */
  	ie_ack(ie->scb, IE_ST_WHENCE & status, unit, ie->ie_chan_attn);
+
+ 	if (ie->hard_type == IE_EE16) /* XXX Heavy traffic sometimes hangs an*/
+ 		DELAY(15);            /* XXX EE16. This delay seems to cure. */

  	if (status & (IE_ST_RECV | IE_ST_RNR)) {
  #ifdef DEBUG


I am also referencing the following PR's, i386/3502, kern/11164, and
kern/15882,
in an effort to combine all these PR's which are all centered on one thing -
how the Intel Etherexpress 16 driver is "a piece of crap" as stated by it's
author. :-)  Follows are a synopsis (I have rewritten the titles for
clarity):


i386/3502:  NFS activity on a system with an E16 hangs the initiating
process.

The details of the symptoms listed on the webpage referenced by the URL in
PR
i386/16214 match i386/3502 - this is the same bug.

kern/11164: Improper table calculations in E16 driver will panic the system

This PR references a patch to correct the driver, without it on cards with
less than 16k memory window the driver crashes.  The submitter listed a
problem with a NI5210 with 8k of ram.  The PR does not state if the patch
was ever applied and is still open.

kern/15882: attempting to ifconfig up an E16 crashes the system

The submitter's system hung during version 3.4 installation.  No further
info
on the submitters system or network was supplied.  I myself have found that
a
FreeBSD 3.4 installation out of the box also will not work with the E16,
with
exactly the same symptoms.  (system hangs as soon as it tries upping the
interface)

On my system, it was plugged into a busy network.  I'd assume the same with
kern/15882.  Thus I conclude that this is also the same bug as in i386/3502
and i386/16214

I HAVE ALSO FOUND that 3com 3c507 cards are NOT recognized by the ie driver.
The driver initialization aborts with an unknown card id error message.

Conclusions:

PR's kern/15882, i386/3502 and i386/16214 all reference the same bug and
should be combined.
Comment 4 Sheldon Hearn freebsd_committer freebsd_triage 2000-03-10 11:07:56 UTC
State Changed
From-To: open->closed

Superseded by PR 16214 
Comment 5 Sheldon Hearn freebsd_committer freebsd_triage 2000-03-10 11:10:10 UTC
State Changed
From-To: closed->open

I am an idiot. :-) 
Comment 6 Mike Barcroft freebsd_committer freebsd_triage 2001-07-21 19:47:51 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 7 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-18 16:14:39 UTC
State Changed
From-To: feedback->closed

Automatic feedback timeout.  If additional feedback that warrants 
the re-opening of this PR is available but not included in the 
audit trail, please include the feedback in a reply to this message 
(preserving the Subject line) and ask that the PR be re-opened.