All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Adrian Bunk <bunk@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew.Morton@hera.kernel.org
Subject: Re: Top 10 kernel oopses for the week ending January 12th, 2008
Date: Sat, 12 Jan 2008 15:41:21 -0800	[thread overview]
Message-ID: <47895021.5090306@linux.intel.com> (raw)
In-Reply-To: <20080112233355.GF17276@does.not.exist>

Adrian Bunk wrote:
> On Sat, Jan 12, 2008 at 03:13:29PM -0800, Arjan van de Ven wrote:
>> Adrian Bunk wrote:
>>> All the other reports only contain the plain trace. Is there any way to 
>>> get more information whether the former is a pattern or not, and to
>>> get this information somehow displayed on the webpage?
>> IF the kernel prints that its tainted or whatever it'll be shown, as well
>> as the exact versions etc etc if they are there.
>> Sadly none of this information is there prior to 2.6.24-rc4.
>> ...
> 
> OK, the problem might actually not be the omission of displaying the 
> tainted information but the omission of considering any relevant 
> context.
> 
> Looking deeper:
> 
> Number #2424 is WARN_ON-after-tainted-oops.
> 
> Is your rank 1 just a symptom that the system is in a bad state after 
> running in what is your rank 8?
> 
> In this case the information when following e.g. #2827 is quite useless 
> since wherever you got this trace from all related context information 
> like e.g. whether it's like #2424 just the symptom of a previous Oops is 
> not displayed.

the tainted flags have a flag for "there was a previous oops", and if that's set,
the kerneloops.org website ignores the report. Simple as that.

> In the worst case, an entry might only contain WARN_ON traces without 
> any information where the traces came from and whether it's worth 
> looking at them or whether the system always already was in a known-bad 
> state when they occured?

again as of 2.6.24-rc4 or so, this is just no longer the case. The problem is with
older kernels which had a WARN_ON() that didn't print ANY information other than
a plain backtrace.

  reply	other threads:[~2008-01-12 23:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12 18:48 Top 10 kernel oopses for the week ending January 12th, 2008 Arjan van de Ven
2008-01-12 22:23 ` Adrian Bunk
2008-01-12 23:13   ` Arjan van de Ven
2008-01-12 23:33     ` Adrian Bunk
2008-01-12 23:41       ` Arjan van de Ven [this message]
2008-01-15 10:36   ` Jiri Kosina

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=47895021.5090306@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=Andrew.Morton@hera.kernel.org \
    --cc=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.