netdev - RE: [E1000-devel] [regression?] e1000e breaks IPMI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <36D9DB17C6DE9E40B059440DB8D95F52056AC3B7@orsmsx418.amr.corp.intel.com>
Date:	Mon, 16 Jun 2008 15:30:24 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"Nikola Ciprich" <extmaillist@...uxbox.cz>,
	<linux-kernel@...r.kernel.org>
Cc:	<nikola.ciprich@...uxbox.cz>, <e1000-devel@...ts.sourceforge.net>,
	<netdev@...r.kernel.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Subject: RE: [E1000-devel] [regression?] e1000e breaks IPMI

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 <auke-jan.h.kok@...el.com>
> 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?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html