Re: e1000e: sporadic "hardware error"s with Intel 82563EB on Supermicro X7DB3

["Hillier, Gernot" <gernot.hillier@siemens.com>]

Hi Dave!

I added Zoltan Fodor from your PAE department to the distribution list as
he also supports us regarding this problem.

Am 15.10.2008 18:37 schrieb Graham, David:
> I think that the system with the SuperMicro IPMI card is configured as 
> having an "external BMC" from the perspective of the INTEL-based system.

Exactly. That's what our hardware experts told me in the meantime, too.

> My experience of such configurations is that the IPMI traffic is handled
>  by the BMC in the card, but routed in/out of the system over the "eth0"
>  on-motherboard esb2 interface. I looked at the AOC-SIMPL-B card 
> described in the SuperMicro link you provided and see that it too has an
>  ethernet interface. I'm not sure if the interface on the card provides
> a second IPMI interface to the system, or that IPMI to the mainboard
> eth0 is disabled. I have IPMI management contacts here in INTEL, and am 
> trying to find out.
> 
> If this system does route IPMI traffic between the SuperMicro card & the
>  mainboard LAN eth0, the onboard LAN now has two clients, one on the 
> SuperMicro card, and one in the host OS.

The latter is true for us. This IPMI card has an own eth interface as you
mentioned, but due to product requirements, we can't use it but need the
"shared NIC" feature. Therefore, this card is configured (jumpered) to
route its IPMI traffic through the eth0 on the motherboard.

> INTEL provides APIs to external BMCs so that they can use the LAN, and
> hidden behind those APIs is code to allow each client to operate without
> having to be aware of the state of the other. There is a bug in this
> code that can be exposed when the host resets the LAN. The bug is
> resolved by a patch to the API code, which is applied as an EEPROM
> update to the system. I am working with Jeff Hockert & others in-house
> to find out details of how we are deploying that EEPROM update.

Thanks for the explanation. I would be more than happy to try anything in
that area!

> I continue to review - with help- the information that you have already 
> provided, to determine whether this system does match the IPMI 
> configuration that I think it does. I'll keep you up to date.

As explained above, your assumptions should exactly apply to our scenario, yes.

> OK, now for the system without the IPMI card. Probably that one does 
> have an active INTEL BMC. And, if it does, the core bug that I (sort-of)
>  explained above is also relevant there, though it's not fixable in the 
> same way because the buggy code in this case is integrated directly as 
> part of the INTEL BMC. In this case, you'll need a BMC upgrade. But 
> first, just like for the other case, I need to confirm that the 
> configuration is what I think it is.
> 
> It would help if you could provide a little more information. Could you 
> provide (for one of each of the two configurations that you have - one 
> with the IPMI card, one without):
> 
> lspci -t 
> lspci -vvv -xxxx
> ethtool -e eth0

I will provide those as soon as possible. Currently, they would be
meeningless for you probably as our hardware experts tried some kind of
firmware update which broke the "Shared NIC" feature - so I doubt we can
reproduce the bug in the current configuration.

As soon, as I can get the machines back to the state where we can reproduce
the issue, I'll send you the requested details.

> BIOS "IPMI" menus (I know you
> already gave us one, but both would be good)

For this, I can already tell that there is no BIOS IPMI menu available if
there's no IPMI card plugged in. Seems like the Supermicro BIOS developers
deny access to the Intel BMC in standalone mode...

-- 
With kind regards,
Gernot Hillier
Siemens AG, CT SE 2, Corporate Competence Center Embedded Linux