Bug 44561 - etherexpress pro/10+ fails under load
Summary: etherexpress pro/10+ fails under load
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-14 05:34 UTC by Brock Nanson
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-06 13:42:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Brock Nanson 2001-06-14 05:34:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

Description of problem:
This NIC has been my nemesis since 5.2!  I've seen reference to using 
eepro.o and eepro100.o and have tried both.  Module loads, pings are OK.  
SSH'ing in for a terminal session will work apparently forever.  FTP, pscp 
(ssh file transfer) will cause the NIC to go deaf after a very short data 
flow (100kB or so).  Does not respond to pings.  Will ping other machines 
(oddly, NICs of the same model have LONG ping times, others are normal).  
Doing a 'network restart' will bring the NIC back.  The maintainer, Aris 
Filho, admitted eepro.o was broken around 2.2.16 but apparently is still 
problematic.  I've worked with several of these cards in Linux Router 
Project boxes and found that the 2.2.17 mandrake module was the only one 
that would work.  Not with 2.4.2 though!

How reproducible:

Steps to Reproduce:
1.Start Network
2.Transfer files

Actual Results:  NIC stops responding to the outside world.  No error 
messages found on local machine.  Appears functional from local machine.

Expected Results:  File transfers should have succeeded!

Additional info:

As in description, maintainer of module has admitted to breaking it around 
2.2.16, but claims to have repaired.

Comment 1 Trond Eivind Glomsrxd 2001-06-14 15:36:31 UTC
Not xinetd-related... reassigning component.

Comment 2 Arjan van de Ven 2001-06-14 15:39:06 UTC
Could you do 2 things for me?
1) try the "e100" driver instead of the "eepro100" (change it in   

2) give me the "lspci" output for the network-card

Comment 3 Brock Nanson 2001-06-15 14:47:56 UTC
With regard to the e100.o module, it seems to load, however the failure is the 
same.  Note, this was tested from an SSH session, not sure if all information 
was conveyed.  As for lspci, this card is ISA and the computer is pre-PCI!  A 
direct response from maintainer suggests a new improved module for 2.2 and 2.4 
is forthcoming.

Comment 4 Brock Nanson 2001-06-16 03:08:23 UTC
My mistake with regard to the e100 and eepro100 modules... they don't load.  
Linuxconf appeared to insert them, but a reboot at the machine showed they 
didn't load (not surprising!).  Only eepro.o loads successfully, but dies as 
described earlier.

Comment 5 Peter Hunter 2001-09-19 10:37:00 UTC
I see this too. Stopping networking, removing the module and then 
reinserting fixes it, but obviously having to do this every few minutes is 
very very annoying. Last version that worked for me was the original 
module which came with Redhat 6.2 - when the 6.2 kernel was updated, 
things were broken.

Comment 6 Jamye Harrison 2001-10-26 06:10:00 UTC
I can confirm that this happens in my setup too. Doing a network restart or a 
full reboot will fix it, but it then dies again about 5 - 10 mins later.

I haven't seen this to be triggered by any particular network operation or 
protocol (unlike some posts above). The interface using this driver will die 
after a while even without use.

Running kernel 2.4.2-12 on a 486 with only ISA support. 3c509 in the machine 
works fine.

Note You need to log in before you can comment on or make changes to this bug.