Red Hat Bugzilla – Bug 38335
eePro100 driver for 2.4 kernel fails under load
Last modified: 2007-04-18 12:32:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
When using Redhat 7.1 with a Tyan s2510ng mb (two on-board intel 82599
10/100 nics), we get a message that the eth0 and eth1 are out of
resources. This is when putting the network under a heavy load with large
On Redhat 7.0 with the old kernel and eepro100 driver, we have no problem.
Steps to Reproduce:
1.Install redhat 7.1 on any machine with two nics with Intel 82599 chips.
2. Transfer 100 30 mb files in series on one nic. Use rcp or scp.
3. Share a nfs directory on the other nic, and copy some of the files.
Actual Results: The pc will freeze up, and messages will come across the
eth0: card reports out of resources
eth1: card reports out of resources
.. etc. etc.
If you are lucky, and there is no freeze, if you init 6, you will see
messages in the un-mounting of the nfs drive that the card reports no
Expected Results: This should work every day and sunday. The intel 82559
is shown in the compatible hardware list, and is produced by the largest
chip company in the world...I mean, give me a break here.
Would you be willing to test the alternative eepro100 driver (called e100)
we ship with 7.1? All you need to do is change eepro100 to e100 in
I'm on it...well report back to you on the test..
I don't get this problem any more...good work! Is this a released driver? A
test, or what?
"e100" is the driver that is officially released by Intel. "eepro100" is the
driver that is in the linux kernel. In the past, the eepro100 was less usable
than the e100 driver (that's why e100 is the default for Red Hat Linux 7.0), but
in the last 8 months or so, the eepro100 driver has had a new maintainer and
has improved to the point that it is at least as good a driver as e100, for most
people. It turns out that eepro100 doesn't work for some people (like you) while
e100 doesn't work well for others.
This is why I ask you to give me the output of "lspci -v" _and_ "lspci -n",
this helps us keeping track of what driver works for which PCI id so we can
make the proper driver the default.
Created attachment 16852 [details]
the listing from lspci -n on a tyan s2510ng mb pc with rh 7.1
Created attachment 16853 [details]
lspci -v from a tyan s2510ng mb computer with rh 7.1
I have the same motherboard (Tyan Thunder LE S2510), and have been having many
lockups lately. It definatly appeared to be related to load. I was on Red Hat
6.2, then recenly upgraded to RH 7.1, hoping this would solve my lockups. I
will try switching the eepro100 driver as well, and if I still get a freeze I
will report back.
ummm, no that does not work. Not I get a problem where the server no longer
responds to tcp/udp requests after a night online. This morning at 9:30, the
server droped all connections. I can ping it, but that's about it. This is very
frustrating, what can I do?
This happens under 7.2 as well, and there is no alternative driver (e100)
7.2 most certainly has the e100 driver.
Also the 2.4.9-13 is supposed to have an improved eepro100 driver; if that
doesn't work please give the (numeric) pci id of the card (see lspci -n) and the
network type (10 or 100Mbit, half or full duplex, hub or switch)
No further feedback - closing
This continues to hang as of 2.4.9-13 with "02:08.0 Class 0200: 8086:2449 (rev 03)
" hardware on busy unswitched 10Mb networks (and, in fact, much more recent 7.3
errata kernels do the same), although I don't believe that it actually
represents a problem given that the eepro100 driver has now been completely
deprecated in favor of e100. I'm not reopening the bug, but if someone is
interested in fixing this for whatever reason, I'm willing to check the
functionality of this driver under the current Red Hat 9 errata kernel (as we
have one horrendous local network which reliably hangs the kernel with the
eepro100 driver), and may be able to provide further help on debugging it.