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 file transfers. On Redhat 7.0 with the old kernel and eepro100 driver, we have no problem. Reproducible: Always 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 terminal: 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 resources. 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 /etc/modules.conf
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) available.
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.