Message-ID: <F169D4F5E1F1974DBFAFABF47F60C10A0D2A5710@orsmsx507.amr.corp.intel.com>
Date:	Fri, 31 Oct 2008 10:09:28 -0700
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	Krzysztof Oledzki <ole@....pl>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"kaber@...sh.net" <kaber@...sh.net>
CC:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"Graham, David" <david.graham@...el.com>
Subject: RE: e1000 kills IPMI on 82541GI (Dell PE1425SC) + small 2.6.27
 regression

<modified the mail list a bit>

Krzysztof Oledzki wrote:
> I have started implementing IPMI on my servers and there is some
> inconvenience with e1000+82541GI (Dell PE1425SC).

ugh, sorry to hear about that.
 
> With older kernels IPMI works if there are no vlans attached to
> primary interface. Adding vlans breaks it as e1000 driver enables
> VLAN filter and it somehow interferences with IPMI.
> 
> (no vlans):
> # ethtool -d eth0|grep -i vlan
>        VLAN mode:                         disabled
>        VLAN filter:                       disabled
> 
> (vlans):
> # ethtool -d eth0|grep -i vlan
>        VLAN mode:                         enabled
>        VLAN filter:                       enabled

vlan enable does a couple of things, it mostly just allows the device to

strip the vlan tag (that matches our vlan table in hardware) from
incoming 
packets and put it in the rx descriptor. This modifies the original 
packet as the vlan is stripped.  
 
> However, I found that using a workaround by adding the IPMI vlan to
> the OS restores the functionality. Very ugly but works.

interesting, this is whith the older <= 2.6.26 kernel right?
 
> So, it is OK with no-vlan-enabled hosts and with vlan-enabled with the
> above workaround, but still - it is a ugly workaround: IPMI is
> non-functional until OS *properly* initializes network configuration,
> which may never happen.

yeah that's pretty ugly, and not acceptable if you're trying to use
IPMI.
 
> Everything becomes much more complicated with more recent kernels
> (2.6.27 for example), where vlan filter is now enabled
> unconditionally and I have to add the dummy IPMI vlan also on
> no-vlan-enabled hosts to make it working. That makes it really
> confusing. 

yeah, that's a not so good regression due to unconditionally turning on
VLAN hardware offload.
 
> So, is it possible to fix this? For example to change the driver to
> read IPMI vlan id and add it to vlan filter regardless of current OS
> configuration? Or maybe it is possible to prevent IPMI from
> interferencing with the current driver's state?

It might be possible to fix this.  The hardware doesn't *have* to 
support VLAN offload in hardware.  This would essentially leave all
packets
unmodified as they arrive.  We will definitely look

So, do you intend that IPMI traffic should be on its own vlan?  Would
this kind of configuration work?  What if the IPMI traffic was *not* on
a vlan
but you had vlans enabled in your network?

Let me summarize, please correct me if I'm wrong:
0) you want to run IPMI traffic on its own VLAN
1) 2.6.26 kernel with vlan enabled IPMI breaks doesn't work until driver
is loaded?
2) 2.6.27 kernel (which enables vlan stripping) breaks IPMI vlan traffic
until "dummy"
   vlan is added with driver (on non-vlan hosts)

I'm feeling a bit confused at this point, can you please describe what
you want to do
with both the host and the ipmi config?

I'll have our lab see if they can reproduce this, I'm not even sure how
many others have
tried IPMI over VLAN.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6703 bytes)

Powered by blists - more mailing lists