Red Hat Bugzilla – Bug 201219
E1000 module kernel panics during stress test
Last modified: 2007-11-30 17:07:26 EST
Description of problem: E1000 module kernel panics during stress test Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. connect crossover to both nic ports (onboard) 2. run burneth script (will attach this to bug) 3. kernel panic Actual results: After running our stress test the script hangs up when it is renegotiating the duplex and kernel panics Expected results: The machine should not kernel panic. Additional info: Attached is the dmesg and the stress test script.
Created attachment 133565 [details] Dmesg
Created attachment 133566 [details] Nic stress test script
Created attachment 133568 [details] Lspci -v
Today i got a chance to try fc6test1 and I encountered the same kernel panic. This time due to the lockdep feature in the new kernel i got a ver nice verbose output that i feel would help out this bug to. Bugzilla: 201374
Test kernels w/ e1000 7.1.9-k4 are available here: http://people.redhat.com/linville/kernels/rhel4/ Please give those a try and post the result here...thanks!
During a 24hour hour test period I experienced no kernel panics. I did however loose 1 of the 2 interfaces sometime between hour 7 and hour 24. I have looked thru /var/log/messages and have not seen anything to say why it was no longer configuring an ip on eth0. I had no errors or anything else out of the ordinary when I did ifconfig -a. Is there any other data I could provide you from the system?
Can you bring-up eth0 manually now? Or is it completely dead?
Yes it can be brought up manually, with dhclient or with the script. It is not hard down.
Ran the stress test script overnight and this time in a 24hour period everything worked fine. I belive someone may have mad some adjustments to the machine for the first test cycle causeing the interface to drop. This time everything was great!
Hmmm...so does that imply that this issue is resolved? Or that it never was a real issue? Or...?
No this was/is a real problem. The 7.1.9-k4 e1000 drivers seem to do the trick. This actually happens on Fedora 5.90 (Core 6 test 1) also.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
committed in stream U5 build 42.28. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0304.html