From: Stephen Hemminger <shemminger@vyatta.com>
To: Jay Cliburn <jacliburn@bellsouth.net>
Cc: David Miller <davem@davemloft.net>,
adobriyan@gmail.com, csnook@redhat.com, netdev@vger.kernel.org
Subject: Re: atl1: WARNING at net/sched/sch_generic.c:221
Date: Sun, 14 Sep 2008 12:58:41 -0700 [thread overview]
Message-ID: <20080914125841.1310c390@speedy> (raw)
In-Reply-To: <20080914142654.3114cb3a@osprey.hogchain.net>
On Sun, 14 Sep 2008 14:26:54 -0500
Jay Cliburn <jacliburn@bellsouth.net> wrote:
> On Thu, 21 Aug 2008 05:08:57 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
> > From: adobriyan@gmail.com
> > Date: Thu, 21 Aug 2008 16:04:09 +0400
> >
> > > On Thu, Aug 21, 2008 at 04:59:10AM -0700, David Miller wrote:
> > > > From: adobriyan@gmail.com
> > > > Date: Thu, 21 Aug 2008 15:58:49 +0400
> > > >
> > > > > This message happens more or less every reboot, sometimes cable
> > > > > unplug/plug is needed to restore connectivity, otherwise card
> > > > > is working fine.
> > > >
> > > > What kernel version.... no, I can figure it out via osmosis never
> > > > mind! :-)
> > >
> > > WARN already prints kernel version. ;-)
> > >
> > > [ 2086.052503] Pid: 0, comm: swapper Not tainted
> > > 2.6.27-rc4-netns-nf #4 ^^^^^^^^^^^^^^^^^^^
> > >
> > > And before you ask, "-netns-nf" part doesn't matter, it happens with
> > > strictly mainline kernels too and started around multiqueue TX
> > > changes, IIRC.
> >
> > It's a simple transmit timeout error.
> >
> > Perhaps atl1 doesn't call netif_carrier_off() in all the places that
> > it should.
>
> For reference, the original report from Alexey on this matter is here:
>
> http://marc.info/?l=linux-netdev&m=121931988219314&w=2
>
> To which Dave responded above, "It's a simple transmit timeout error."
>
> Should a netdev driver be coded such that a watchdog transmit timeout
> never occurs?
>
> [ 2086.049998] NETDEV WATCHDOG: eth0 (atl1): transmit timed out
>
> Or is a watchdog timeout an expected occurrence if a cable is
> unplugged/plugged?
Any transmit timeout is driver or hardware bug. The driver should be
shutting down transmit correctly on cable pull.
next prev parent reply other threads:[~2008-09-14 19:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-21 11:58 atl1: WARNING at net/sched/sch_generic.c:221 adobriyan
2008-08-21 11:59 ` David Miller
2008-08-21 12:04 ` adobriyan
2008-08-21 12:08 ` David Miller
2008-09-14 19:26 ` Jay Cliburn
2008-09-14 19:58 ` Stephen Hemminger [this message]
2008-09-14 23:56 ` David Miller
2008-09-15 0:11 ` Jay Cliburn
2008-09-15 3:14 ` Jeff Garzik
2008-08-22 2:00 ` Jay Cliburn
2008-08-22 21:50 ` Jay Cliburn
2008-09-14 23:17 ` Jay Cliburn
2008-09-15 22:45 ` Alexey Dobriyan
2008-09-16 1:44 ` Jay Cliburn
2008-09-17 7:44 ` Alexey Dobriyan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080914125841.1310c390@speedy \
--to=shemminger@vyatta.com \
--cc=adobriyan@gmail.com \
--cc=csnook@redhat.com \
--cc=davem@davemloft.net \
--cc=jacliburn@bellsouth.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.