[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1300478286.2589.29.camel@bwh-desktop>
Date: Fri, 18 Mar 2011 19:58:06 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: David Miller <davem@...emloft.net>
Cc: shemminger@...tta.com, eric.dumazet@...il.com, jdb@...x.dk,
netdev@...r.kernel.org, nhorman@...driver.com,
alexander.h.duyck@...el.com
Subject: Re: LRO disable warnings on kernel 2.6.38
On Fri, 2011-03-18 at 12:52 -0700, David Miller wrote:
> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Fri, 18 Mar 2011 08:15:24 -0700
>
> > On Fri, 18 Mar 2011 15:33:04 +0100
> > Eric Dumazet <eric.dumazet@...il.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.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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
Powered by blists - more mailing lists