Bug 496248 - When the network is initialized by e1000e driver, I lose connection to the IPMI card
Summary: When the network is initialized by e1000e driver, I lose connection to the IP...
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Peter Martuccelli
QA Contact: Red Hat Kernel QE team
URL: http://bugs.centos.org/view.php?id=3477
Depends On:
TreeView+ depends on / blocked
Reported: 2009-04-17 14:27 UTC by Luis
Modified: 2012-01-20 23:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-12-23 16:04:55 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
CentOS 3477 None None None Never

Description Luis 2009-04-17 14:27:36 UTC
Description of problem:

The card still responds correctly using the proprietary Supermicro tools, and also with ipmitool. Just not remotely. 

Version-Release number of selected component (if applicable): 
e1000e: Intel(R) PRO/1000 Network Driver -
CentOS 5.3

How reproducible: 

Motherboard SuperMicro and SuperMicro IPMI card

Steps to Reproduce:
1. Start CentOS 5.3
2. Remote connection with OpenIPMI tool
Actual results: Non functional

Comment 2 Jan Safranek 2009-04-20 08:18:09 UTC
If I understand it correctly, this is kernel problem.

Comment 3 Bas Mevissen 2009-05-04 11:18:49 UTC
The report is corrrect. I see the same problem with Supermicro server PDSMI+ motherboard and AOC-IPMI20-E IPMI card. I already had the IPMI card returned and replaced in vain... When rebooting an older kernel (2.6.18-92.1.18.el5xen), the IPMI starts working again.

See commit eb7c3adb1ca92450870dbb0d347fc986cd5e2af4 that is included in kernel patch-2.6.28-rc5-git2. This should urgently be back ported to 2.6.18 and noted in the errata.

Comment 4 Bas Mevissen 2009-06-02 09:12:07 UTC
What is the current status? Will the fix for this issue be included in the next kernel for RHEL?

Comment 5 Luis 2009-06-02 09:28:48 UTC
I continue with the same problem and with the last kernel.

uname -a 

Comment 6 Bas Mevissen 2009-06-25 07:19:31 UTC
Kernel 2.6.18-128.1.14.el5xen still seems to contain the broken driver version So I guess nothing has changed to it.

Work-around in http://bugs.centos.org/view.php?id=3477

Comment 7 Ryan Dooley 2009-10-02 18:46:52 UTC
I'm actually seeing this behavior with with 2.6.18-164.el5.x86_64, the bnx2 driver that comes with it (1.9.3 I believe), and the Dell R710 platform.

The system comes up just fine with SOL over IPMI and as soon as the bnx2 driver takes over I lose IPMI.  If I ssh to the machine and /sbin/reboot, as soon as the driver is unloaded, IPMI comes back.

I've downloaded and installed Broadcom's lastest netxtreme2 driver (1.9.20b5). 

I've flashed the BIOS to the latest version (1.2.6) as well as the iDRAC firmware (to 1.20.1). None of it has helped much.

Comment 9 Jarod Wilson 2009-10-08 14:41:10 UTC
(In reply to comment #7)
> I'm actually seeing this behavior with with 2.6.18-164.el5.x86_64, the bnx2
> driver that comes with it (1.9.3 I believe), and the Dell R710 platform.

This bug is specific to hardware driven by the e1000e driver, you've got a similar-but-different problem, which should be filed under another bug.

Comment 12 Ryan Dooley 2009-10-09 00:15:55 UTC
Actually this turned out to be Ganglia+Multicast for me.  The Dell iDRAC is running some OS (Linux?) that was attempting to process the multicast traffic. Turn off Ganglia and the shared bnx2 connection does the right thing.

Comment 13 Bas Mevissen 2009-12-20 18:31:28 UTC
Well, it looks like things have improved. Kernel 2.6.18-164.9.1.el5xen seems to contain a version of the e1000e kernel driver that supports the CrcStripping option. So on SuperMicro boards, one needs to add a file in the /etc/modprobe.d directory containing the line

options e1000e CrcStripping=0

Can this added to the errata?

Comment 14 Jarod Wilson 2009-12-23 16:04:55 UTC
The CrcStripping option was actually added in the 5.4 kernels, so this bug is already fixed, as far as I can see. We don't typically update an errata after it has already been released. Could be a candidate for adding a knowledgebase article for, but I don't know offhand how to make that happen...

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