All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: David Miller <davem@davemloft.net>
Cc: kuba@kernel.org, arjan@linux.intel.com, xiyou.wangcong@gmail.com,
	jhs@mojatatu.com, jiri@resnulli.us, 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:40:05 +0300	[thread overview]
Message-ID: <20200403044005.GD80989@unreal> (raw)
In-Reply-To: <20200402.180218.940555077368617365.davem@davemloft.net>

On Thu, Apr 02, 2020 at 06:02:18PM -0700, David Miller 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'm not applying this, sorry.

Dave,

In our case, it is HW bug and I'm looking for a way to silence dump
stack. Do I have any way to avoid WARN here?

It will be a little bit overkill to add some special flag to general
netdev structure just to mark that mlx4 doesn't need this trace.

Thanks

      parent reply	other threads:[~2020-04-03  4:40 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
2020-04-03  4:40   ` Leon Romanovsky [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=20200403044005.GD80989@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.