public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Matt Mackall <mpm@selenic.com>
Cc: Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
	Ingo Molnar <mingo@elte.hu>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	John B?ckstrand <sandos@home.se>
Subject: Re: [PATCH] netpoll can lock up on low memory.
Date: Fri, 05 Aug 2005 20:23:55 -0400	[thread overview]
Message-ID: <1123287835.18332.110.camel@localhost.localdomain> (raw)
In-Reply-To: <20050805212808.GV8074@waste.org>

On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote:
> 
> Netpoll generally must assume it won't get a second chance, as it's
> being called by things like oops() and panic() and used by things like
> kgdb. If netpoll fails, the box is dead anyway.
> 

But it is also being called by every printk in the kernel. What happens
when the printk that causes this lock up is not a panic but just some
info print.  One would use netconsole when they turn on more verbose
printing, to keep the output fast, right?  So if the system gets a
little memory tight, but not to the point of failing, this will cause a
lock up and no one would know why. 

If you need to really get the data out, then the design should be
changed.  Have some return value showing the failure, check for
oops_in_progress or whatever, and try again after turning interrupts
back on, and getting to a point where the system can free up memory
(write to swap, etc).  Just a busy loop without ever getting a skb is
just bad.

> > > The netpoll philosophy is to assume that its traffic is an absolute
> > > priority - it is better to potentially hang trying to deliver a panic
> > > message than to give up and crash silently.
> > 
> > So even a long timeout would not do?  So you don't even get a message to
> > the console?
> 
> In general, there's no way to measure time here. And if we're
> using netconsole, what makes you think there's any other console?

Why assume that there isn't another console?  The screen may be used
with netconsole, you just lose whatever has been scrolled too far.

> 
> > > > Also, as Andi told me, the printk here would probably not show up
> > > > anyway if this happens with netconsole.
> > > 
> > > That's fine. But in fact, it does show up occassionally - I've seen
> > > it.
> > 
> > Then maybe what Andi told me is not true ;-)
> > 
> > Oh, and did your machine crash when you saw it?  Have you seen it with
> > the e1000 driver?
> 
> No and no. Most of my own testing is done with tg3.
> 

If you saw the message and the system didn't crash, then that's proof
that if the driver is not working properly, you would have lock up the
system, and the system was _not_ in a state that it _had_ to get the
message out.

-- Steve



  reply	other threads:[~2005-08-06  0:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42F347D2.7000207@home.se.suse.lists.linux.kernel>
2005-08-05 11:45 ` lockups with netconsole on e1000 on media insertion Andi Kleen
2005-08-05 12:44   ` John Bäckstrand
2005-08-05 13:49   ` Steven Rostedt
2005-08-05 13:55     ` Andi Kleen
2005-08-05 14:10       ` Steven Rostedt
2005-08-05 14:14         ` Andi Kleen
2005-08-05 14:27           ` Steven Rostedt
2005-08-05 14:36             ` David S. Miller
2005-08-05 15:02               ` Steven Rostedt
2005-08-05 14:36           ` [PATCH] netpoll can lock up on low memory Steven Rostedt
2005-08-05 20:01             ` Matt Mackall
2005-08-05 20:57               ` Steven Rostedt
2005-08-05 21:28                 ` Matt Mackall
2005-08-06  0:23                   ` Steven Rostedt [this message]
2005-08-06  1:53                     ` Matt Mackall
2005-08-06  2:32                       ` Steven Rostedt
2005-08-06  7:30                         ` Daniel Phillips
2005-08-06  7:58                         ` Ingo Molnar
2005-08-06 23:10                           ` Matt Mackall
2005-08-06  9:46                         ` David S. Miller
2005-08-06  9:57                           ` Steven Rostedt
2005-08-06 12:09                             ` John Bäckstrand
2005-08-07  5:40                             ` Matt Mackall
2005-08-05 21:26               ` Andi Kleen
2005-08-05 21:42                 ` Matt Mackall
2005-08-05 21:51                   ` Andi Kleen
2005-08-06  1:16                     ` Matt Mackall
2005-08-06  0:30                 ` Steven Rostedt
2005-08-06  7:45                 ` Ingo Molnar
2005-08-06 11:29                   ` Andi Kleen
2005-08-07 21:12     ` lockups with netconsole on e1000 on media insertion John Bäckstrand
2005-08-08  2:29       ` Steven Rostedt
2005-08-05 20:12   ` Matt Mackall
2005-08-05 21:56     ` Andi Kleen
2005-08-05 23:20       ` Matt Mackall
2005-08-05 23:51         ` Andi Kleen
2005-08-06  1:22           ` Matt Mackall
2005-08-06  1:37             ` Daniel Phillips

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=1123287835.18332.110.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mpm@selenic.com \
    --cc=netdev@vger.kernel.org \
    --cc=sandos@home.se \
    /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