| Summary: | Driver for Intel EtherExpress 16 is unreliable, (if_ie.c) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | fitz <fitz> |
| Component: | i386 | Assignee: | 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
<<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 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 > 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.
State Changed From-To: open->closed Superseded by PR 16214 State Changed From-To: closed->open I am an idiot. :-) State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE? 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. |