All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Jamal Hadi Salim <jhs@mojatatu.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	itayav@mellanox.com
Subject: Re: [PATCH net] net/sched: Don't print dump stack in event of transmission timeout
Date: Fri, 3 Apr 2020 07:36:11 +0300	[thread overview]
Message-ID: <20200403043611.GC80989@unreal> (raw)
In-Reply-To: <CAM_iQpWvkTTRwV5-tj1Hj_a8hG2X-udU0BG2VXDbukuKFeN=JA@mail.gmail.com>

On Thu, Apr 02, 2020 at 09:30:15PM -0700, Cong Wang wrote:
> On Thu, Apr 2, 2020 at 6:02 PM David Miller <davem@davemloft.net> wrote:
> >
> > From: Leon Romanovsky <leon@kernel.org>
> > Date: Thu,  2 Apr 2020 18:23:36 +0300
> >
> > > In event of transmission timeout, the drivers are given an opportunity
> > > to recover and continue to work after some in-house cleanups.
> > >
> > > Such event can be caused by HW bugs, wrong congestion configurations
> > > and many more other scenarios. In such case, users are interested to
> > > get a simple  "NETDEV WATCHDOG ... " print, which points to the relevant
> > > netdevice in trouble.
> > >
> > > The dump stack printed later was added in the commit b4192bbd85d2
> > > ("net: Add a WARN_ON_ONCE() to the transmit timeout function") to give
> > > extra information, like list of the modules and which driver is involved.
> > >
> > > While the latter is already printed in "NETDEV WATCHDOG ... ", the list
> > > of modules rarely needed and can be collected later.
> > >
> > > So let's remove the WARN_ONCE() and make dmesg look more user-friendly in
> > > large cluster setups.
> >
> > Software bugs play into these situations and on at least two or three
> > occasions I know that the backtrace hinted at the cause of the bug.
> >
>
> I don't see how a timer stack trace could help to debug this issue
> in any scenario, the messages out of this stack trace are indeed
> helpful.
>
> On the other hand, a stack trace does help to get some attention
> via ABRT, but at least for us we now use rasdaemon to capture
> this, so I am 100% fine to remove this stack trace.

Thanks

>
> Thanks.

  reply	other threads:[~2020-04-03  4:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-02 15:23 [PATCH net] net/sched: Don't print dump stack in event of transmission timeout Leon Romanovsky
2020-04-02 22:57 ` Jakub Kicinski
2020-04-03  4:33   ` Cong Wang
2020-04-03  4:48   ` Leon Romanovsky
2020-04-03  1:02 ` David Miller
2020-04-03  4:30   ` Cong Wang
2020-04-03  4:36     ` Leon Romanovsky [this message]
2020-04-03  4:40   ` Leon Romanovsky

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=20200403043611.GC80989@unreal \
    --to=leon@kernel.org \
    --cc=arjan@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=itayav@mellanox.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@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 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.