| Message ID | 1300453519.2888.118.camel@edumazet-laptop |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Fri, 2011-03-18 at 14:05 +0100, Eric Dumazet wrote: > Le vendredi 18 mars 2011 à 12:12 +0100, Jesper Dangaard Brouer a écrit : > > Hi > > > > I'm seeing the LRO disable warnings using kernel 2.6.38: > > > > [ 8.664759] NET: Registered protocol family 10 > > [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready > > [ 8.872639] ------------[ cut here ]------------ > > [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80() > > [ 8.872647] Hardware name: ProLiant DL370 G6 > > [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan] > > [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2 > > [ 8.872662] Call Trace: > > [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0 > > [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20 > > [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80 > > [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180 > > [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0 > > [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20 > > [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180 > > [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90 > > [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b > > [ 8.872714] ---[ end trace 6245283cb8d484cc ]--- > > > > The strange part is that I didn't see this warning on my testlab and > > pre-prod servers. The warning is from the first production server, > > which got kernel 2.6.38 deployed this morning. > > > > The NIC driver is igb. > > > > The only difference in hardware between the production and > > pre-production server (which didn't show the warning), is the > > prod-server have an extra dual-port original Intel NIC, dev-named > > "eth71". And its just after the init of eth71, the warning occurs. > > > > We usually use a 6 port NIC from Hotlava, which is based on the same > > chip 82576 and also uses the same igb driver. > > > > Intel orig NIC eth71 > > albpd4:~# ethtool -i eth71 > > driver: igb > > version: 2.1.0-k2 > > firmware-version: 1.2-1 > > bus-info: 0000:21:00.0 > > > > Hotlava Intel chip based NIC eth51: > > albpd4:~# ethtool -i eth51 > > driver: igb > > version: 2.1.0-k2 > > firmware-version: 1.2-1 > > bus-info: 0000:1d:00.1 > > > > I don't understand why I don't see the warning on my pre-prod server, > > which only have the Hotlava NIC?!? > > > > Hmm, WARN_ON() message is not very nice in this case I'm afraid, we dont > even know offender WARN is correct as this is a driver bug. But I agree that the device/driver ID should be included. Ben. > diff --git a/net/core/dev.c b/net/core/dev.c > index 0b88eba..571ab70 100644 > --- a/net/core/dev.c > +++ b/net/core/dev.c > @@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev) > dev->ethtool_ops->set_flags(dev, flags); > } > } > - WARN_ON(dev->features & NETIF_F_LRO); > + if (dev->features & NETIF_F_LRO) > + netdev_err(dev, "Could not disable LRO\n"); > } > EXPORT_SYMBOL(dev_disable_lro); > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit : > WARN is correct as this is a driver bug. But I agree that the > device/driver ID should be included. stack trace gives absolutely no useful indication here. Bug is in driver, yet we dump information on core network stack ? pr_err() is an error indication, not a warning by the way ;) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 18 Mar 2011 15:33:04 +0100 Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit : > > > WARN is correct as this is a driver bug. But I agree that the > > device/driver ID should be included. > > stack trace gives absolutely no useful indication here. > > Bug is in driver, yet we dump information on core network stack ? > > pr_err() is an error indication, not a warning by the way ;) The advantage of WARN is that it doesn't get ignored and shows up in kernel oops. But agreed it should print out as much device info as possible to finger the broken device driver. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Stephen Hemminger <shemminger@vyatta.com> Date: Fri, 18 Mar 2011 08:15:24 -0700 > On Fri, 18 Mar 2011 15:33:04 +0100 > Eric Dumazet <eric.dumazet@gmail.com> wrote: > >> Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit : >> >> > WARN is correct as this is a driver bug. But I agree that the >> > device/driver ID should be included. >> >> stack trace gives absolutely no useful indication here. >> >> Bug is in driver, yet we dump information on core network stack ? >> >> pr_err() is an error indication, not a warning by the way ;) > > The advantage of WARN is that it doesn't get ignored and shows > up in kernel oops. But agreed it should print out as much device > info as possible to finger the broken device driver. Infrastructure is not static, therefore we could add a WARN_ON_NETDEV() or similar. An in fact such things would probably be very useful. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2011-03-18 at 12:52 -0700, David Miller wrote: > From: Stephen Hemminger <shemminger@vyatta.com> > Date: Fri, 18 Mar 2011 08:15:24 -0700 > > > On Fri, 18 Mar 2011 15:33:04 +0100 > > Eric Dumazet <eric.dumazet@gmail.com> wrote: > > > >> Le vendredi 18 mars 2011 à 14:17 +0000, Ben Hutchings a écrit : > >> > >> > WARN is correct as this is a driver bug. But I agree that the > >> > device/driver ID should be included. > >> > >> stack trace gives absolutely no useful indication here. > >> > >> Bug is in driver, yet we dump information on core network stack ? > >> > >> pr_err() is an error indication, not a warning by the way ;) > > > > The advantage of WARN is that it doesn't get ignored and shows > > up in kernel oops. But agreed it should print out as much device > > info as possible to finger the broken device driver. > > Infrastructure is not static, therefore we could add a WARN_ON_NETDEV() > or similar. An in fact such things would probably be very useful. You mean like netdev_WARN()? :-) Ben.
From: Ben Hutchings <bhutchings@solarflare.com> Date: Fri, 18 Mar 2011 19:58:06 +0000 > You mean like netdev_WARN()? :-) Perfect, but it's be nice if we had a variant where the condition were embedded into the macro as well. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/core/dev.c b/net/core/dev.c index 0b88eba..571ab70 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev) dev->ethtool_ops->set_flags(dev, flags); } } - WARN_ON(dev->features & NETIF_F_LRO); + if (dev->features & NETIF_F_LRO) + netdev_err(dev, "Could not disable LRO\n"); } EXPORT_SYMBOL(dev_disable_lro);