Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 44561 - etherexpress pro/10+ fails under load
etherexpress pro/10+ fails under load
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2001-06-14 01:34 EDT by Brock Nanson
Modified: 2007-04-18 12:33 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Brock Nanson 2001-06-14 01:34:19 EDT
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 11:36:31 EDT
Not xinetd-related... reassigning component.
Comment 2 Arjan van de Ven 2001-06-14 11:39:06 EDT
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 10:47:56 EDT
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-15 23:08:23 EDT
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 06:37:00 EDT
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 02:10:00 EDT
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.