Hi,
it seems that e1000e breaks IPMI support on at least some motherboards (ie SuperMicro PDSMi-LN4 with AOC-IPMI20-E+ module, and also others).
When e1000e module is loaded, IPMI module stops to respond. The problem is, that it was working before, so I tried examining further and bisect showed that following commit caused it to stop working:
commit 5918bd88effd0233a048983570ec5803f5f753dc
Author: Auke Kok <[email protected]>
Date: Tue Feb 12 15:20:24 2008 -0800
e1000e: Fix CRC stripping in hardware context bug
CRC stripping was only correctly enabled for packet split recieves
which is used when receiving jumbo frames. Correctly enable SECRC
also for normal buffer packet receives.
Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.
Signed-off-by: Auke Kok <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
I can confirm that reverting the patch makes IPMI work again. So it either is a regression, or maybe just trigger for some other bug (seems more likely to me). Pity I haven't noticed it sooner, we've been using older e1000[e] drivers up to now.
Any suggestions on where the problem could be?
cheers
nik
--
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
http://www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: [email protected]
-------------------------------------
Nikola Ciprich wrote:
> Hi,
> it seems that e1000e breaks IPMI support on at least some
> motherboards (ie SuperMicro PDSMi-LN4 with AOC-IPMI20-E+ module, and
> also others).
> When e1000e module is loaded, IPMI module stops to respond. The
> problem is, that it was working before, so I tried examining further
> and bisect showed that following commit caused it to stop working:
thank you for bisecting.
also, I added netdev so the network developers are aware of this thread.
> commit 5918bd88effd0233a048983570ec5803f5f753dc
> Author: Auke Kok <[email protected]>
> Date: Tue Feb 12 15:20:24 2008 -0800
>
> e1000e: Fix CRC stripping in hardware context bug
>
> CRC stripping was only correctly enabled for packet split recieves
> which is used when receiving jumbo frames. Correctly enable SECRC
> also for normal buffer packet receives.
At one point I fixed a similar bug in e1000 on 82546 hardware that was
connected to a BMC. In that case the packets were being discarded by a
BMC that is apparently unable to understand that the hardware is
stripping the CRC at reception (and then the BMC looks for the CRC and
drops the packet because there isn't one)
Basically this works fine for Intel BMC's that know about the (AFAIK -
I'm not a BMC expert) special fields in the SMBUS header that indicate
whether the packet was CRCd correctly. Does the BMC have an option to
turn off CRC checking? The BMC is the real problem here, probably.
> I can confirm that reverting the patch makes IPMI work again. So it
> either is a regression, or maybe just trigger for some other bug
> (seems more likely to me). Pity I haven't noticed it sooner, we've
> been using older e1000[e] drivers up to now.
>
> Any suggestions on where the problem could be?
I'm pretty sure that if you disable hardware stripping then it will
start working. The short term solution is change the code to disable
setting the SECRC bit, like you did when you reverted the patch.
There is a possible complex patch that completely implements software
stripping of CRCs, because there are a lot of issues with doing
pskb_trim, etc in receive. It would be modeled on the same kind of
thing we did for e1000.
I hate working around this broken BMC (again) when others are known to
work just fine, and CRC stripping in hardware really simplifies our
receive path.
Netdev, any advice?
> I hate working around this broken BMC (again) when others are known to
> work just fine, and CRC stripping in hardware really simplifies our
> receive path.
Due to rather bad experiences I'm always alarmed about IPMI problems (actually
so far not with supermicro, but with other vendors). So I contacted
supermicro and immediately got an answer they have a new LAP EEPROM to fix
this problem.
So the problem with supermicro is solved, lets see what the other vendor, I
also contacted, says.
--
Bernd Schubert
Q-Leap Networks GmbH