From: Steven Rostedt <rostedt@goodmis.org>
To: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
linux- stable <stable@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Netdev <netdev@vger.kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
Masami Hiramatsu <masami.hiramatsu@linaro.org>,
Leo Yan <leo.yan@linaro.org>, Jamal Hadi Salim <jhs@mojatatu.com>,
Cong Wang <xiyou.wangcong@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
"David S. Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
<lkft-triage@lists.linaro.org>, LTP List <ltp@lists.linux.it>
Subject: Re: NETDEV WATCHDOG: WARNING: at net/sched/sch_generic.c:442 dev_watchdog
Date: Wed, 19 Aug 2020 15:17:01 -0400 [thread overview]
Message-ID: <20200819151701.747769ce@oasis.local.home> (raw)
In-Reply-To: <20200819102909.000016ac@intel.com>
On Wed, 19 Aug 2020 10:29:09 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> What I don't understand in the stack trace is this:
> > > [ 107.654661] Call Trace:
> > > [ 107.657735] <IRQ>
> > > [ 107.663155] ? ftrace_graph_caller+0xc0/0xc0
> > > [ 107.667929] call_timer_fn+0x3b/0x1b0
> > > [ 107.672238] ? netif_carrier_off+0x70/0x70
> > > [ 107.677771] ? netif_carrier_off+0x70/0x70
> > > [ 107.682656] ? ftrace_graph_caller+0xc0/0xc0
> > > [ 107.687379] run_timer_softirq+0x3e8/0xa10
> > > [ 107.694653] ? call_timer_fn+0x1b0/0x1b0
> > > [ 107.699382] ? trace_event_raw_event_softirq+0xdd/0x150
> > > [ 107.706768] ? ring_buffer_unlock_commit+0xf5/0x210
> > > [ 107.712213] ? call_timer_fn+0x1b0/0x1b0
> > > [ 107.716625] ? __do_softirq+0x155/0x467
>
>
> If the carrier was turned off by something, that could cause the stack
> to timeout since it appears the driver didn't call this itself after
> finishing all transmits like it normally would have.
>
> Is the trace above correct? Usually the ? indicate unsure backtrace due
> to missing symbols, right?
The "?" means that there wasn't a stack frame to confirm that this was
the true call stack. What happens is that the scan of the stack will
look for any address in the stack that is for a function. If it finds
one, it will print it and add a "?" to that address. Basically, those
functions with the "?" are just addresses found in the stack but was not
part of a stack frame link.
-- Steve
prev parent reply other threads:[~2020-08-19 19:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 11:31 NETDEV WATCHDOG: WARNING: at net/sched/sch_generic.c:442 dev_watchdog Naresh Kamboju
2020-08-19 16:57 ` Steven Rostedt
2020-08-19 17:29 ` Jesse Brandeburg
2020-08-19 19:17 ` Steven Rostedt [this message]
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=20200819151701.747769ce@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=jesse.brandeburg@intel.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=ltp@lists.linux.it \
--cc=masami.hiramatsu@linaro.org \
--cc=naresh.kamboju@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).