[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <99737F4847ED0A48AECC9F4A1974A4B80FD10E8429@MNEXMB2.qlogic.org>
Date: Mon, 21 Mar 2011 05:00:31 -0500
From: Amit Salecha <amit.salecha@...gic.com>
To: Eric Dumazet <eric.dumazet@...il.com>,
Jesper Dangaard Brouer <hawk@...x.dk>
CC: Alexander Duyck <alexander.h.duyck@...el.com>,
netdev <netdev@...r.kernel.org>,
Neil Horman <nhorman@...driver.com>,
Stanislaw Gruszka <sgruszka@...hat.com>
Subject: RE: LRO disable warnings on kernel 2.6.38
> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Eric Dumazet
> Sent: Monday, March 21, 2011 3:15 PM
> To: Jesper Dangaard Brouer
> Cc: Alexander Duyck; netdev; Neil Horman; Stanislaw Gruszka
> Subject: Re: LRO disable warnings on kernel 2.6.38
>
> Le lundi 21 mars 2011 à 10:21 +0100, Jesper Dangaard Brouer a écrit :
> > On Fri, 2011-03-18 at 09:18 -0700, Alexander Duyck wrote:
> > > On 3/18/2011 4:12 AM, Jesper Dangaard Brouer wrote:
> > > > Hi
> > > >
> > > > I'm seeing the LRO disable warnings using kernel 2.6.38:
> > [...]
> > > >
> > > The error doesn't make any sense for igb to be triggering since it
> > > doesn't support setting the NETIF_F_LRO flag in the 2.6.38 kernel.
> > >
> > > By any chance are there any ixgbe or other interfaces in the
> system? I
> > > would suspect the error to come from a driver that at least
> contains the
> > > NETIF_F_LRO flag.
> >
> > The servers actually also have a four port semi-build in NIC (its a
> PCIe
> > slot with an extra connector, most likely for controlling the LEDs).
> I
> > don't use that NIC as it (1) caused kernel panics on 2.6.35, (2)
> needs a
> > firmware blob, (3) reading through the driver code (at some point in
> > time) they didn't implement multiqueue support correctly.
> >
> > So lets blame that driver ;-)
> >
> > lspci-info:
> > Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-
> Gigabit Server Adapter (rev 42)
> >
> > driver info via ethtool:
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.530
> > bus-info: 0000:06:00.3
> >
> > The strange part is that my pre-prod server also have a netxen_nic,
> but
> > it does not result in a WARN being tricked...
> >
> > The pre-prod server do have a different firmware version.
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.406
> > bus-info: 0000:06:00.0
> >
> > (I have pulled the NIC out of some of the prod server, due to the
> risk
> > of a kernel panic on the old kernel. As operations have taken over
> the
> > deployment process, these NICs are still in. Guess I'll ask them to
> > blacklist the driver, so they don't see the warn stacktrace, they get
> so
> > nervous when they see stuff like that ;-))
> >
>
> Well, this warning can be ignored since these NIC dont receive packets
> to be forwarded in your setup.
>
> I would say netxen_nic_set_flags() is buggy : It rejects data if other
> flag than ETH_FLAG_LRO is set.
>
> if (data & ~ETH_FLAG_LRO)
> return -EINVAL;
>
> Brought by commit ef2519b1dd39940 (netxen: fail when try to setup
> unsupported features) later corrected by commit 97d1935a61b7fe7a65f98f
> (Make ethtool_ops::set_flags() return -EINVAL for unsupported flags)
>
> Since this drivers asserts NETIF_F_HW_VLAN_TX (mirroring
> ETH_FLAG_TXVLAN), ethtool_op_get_flags() can return more than
> ETH_FLAG_LRO.
>
> dev_disable_lro() then calls netxen_nic_set_flags() with
> ETH_FLAG_TXVLAN
> -> -EINVAL, and ETH_FLAG_LRO stay ORed in dev->features -> WARNING
>
>
Thanks Eric.
Instead of
if (data & ~ETH_FLAG_LRO)
return -EINVAL;
check should be like this:
+ if ((ethtool_op_get_flags(netdev) & ~ETH_FLAG_LRO) !=
+ (data & ~ETH_FLAG_LRO))
return -EINVAL;
Will provide patch soon.
-Amit
>
>
>
> --
> 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
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
Powered by blists - more mailing lists