[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0710310653190.12724@gandalf.stny.rr.com>
Date: Wed, 31 Oct 2007 06:58:46 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Andi Kleen <andi@...stfloor.org>
cc: Christoph Hellwig <hch@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, Daniel Walker <dwalker@...sta.com>
Subject: Re: [PATCH] dump_stack on panic
--
On Wed, 31 Oct 2007, Andi Kleen wrote:
> On Wed, Oct 31, 2007 at 08:15:13AM +0000, Christoph Hellwig wrote:
> > On Wed, Oct 31, 2007 at 01:14:04AM +0100, Andi Kleen wrote:
> > > One (mostly psychological, but still serious) problem is that stack
> > > dumps make panics always look like kernel bugs. But there are panics
> > > which are definitely not kernel bugs: like the popular cannot mount
> > > root or machine checks or a couple of others.
> >
> > But that one really shouldn't be a panic anyway. The panic alone
> > is psycologically bad enough for users. I think it would be best to
> > have a simple scanf loop asking for another root device..
>
> Then you couldn't recover with panic=30 from it.
>
> Besides even if you fix that one there are others, like machine checks
> where it is impossible to recover.
Thinking about this more. Of the Linux users I asked, they think a kernel
panic is a bug in the kernel anyway (or at least something in the kernel
went wrong). So if panics will point users to the kernel anyway, then why
leave out possible vital information from those panics that were caused by
an actual kernel bug.
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists