public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Brownell <david-b@pacbell.net>,
	linux-kernel@vger.kernel.org,
	linux-pm@lists.linux-foundation.org, pavel@suse.cz
Subject: Re: [patch 2.6.26-rc4-git] PM: boot time suspend selftest
Date: Fri, 30 May 2008 12:59:48 +0200	[thread overview]
Message-ID: <20080530105948.GA12236@elte.hu> (raw)
In-Reply-To: <20080529162257.03426e48.akpm@linux-foundation.org>


* Andrew Morton <akpm@linux-foundation.org> wrote:

> > +	WARN_ON_ONCE(msec > (TEST_SUSPEND_SECONDS * 1000));
> 
> We should have a comment here explaining what we're warning about.  
> Why would it take more that five seconds?

i asked for that because we had regressions in the past in the form of 
"it takes one minute to resume".

> Better might be to just add a nice printk - I don't think we need the 
> stack trace here.

please keep the warn-on so that it can be detected automatically. Adding 
yet another printk just complicates the automated answer to the "is this 
kernel that just booted up fine or not" question.

In fact i'd love to have the analogue to /proc/lockdep_debug's 
"debug_locks: 0" output. I.e. the kernel should know it via one central 
flag whether any bugs that need human review have been detected so far. 

Say /proc/sys/kernel/kernel_is_buggy. This value could even be 
multi-level: a WARN_ON() increases it by +1, a kernel crash increases it 
by +1000. ( That way i could run overnight tests that will only stop on 
a kernel_is_buggy >= 1000 condition, while it could ignore simpler 
WARN_ON()s. )

	Ingo

  reply	other threads:[~2008-05-30 11:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-29 20:33 [patch 2.6.26-rc4-git] PM: boot time suspend selftest David Brownell
2008-05-29 21:01 ` Rafael J. Wysocki
2008-05-29 21:26   ` David Brownell
2008-05-29 21:29     ` Rafael J. Wysocki
2008-05-29 23:06       ` Andrew Morton
2008-05-30  4:34         ` David Brownell
2008-05-29 23:22 ` Andrew Morton
2008-05-30 10:59   ` Ingo Molnar [this message]
2008-05-30 19:04     ` Andrew Morton
2008-06-03  9:27   ` [PATCH] add a printk_init variant storing format strings in __initdata Andy Whitcroft
2008-06-03 16:41     ` Johannes Weiner
2008-06-03 17:49     ` [linux-pm] " Johannes Berg
2008-06-04  8:16     ` Andrew Morton
2008-06-04  8:32       ` MinChan Kim
2008-06-04  8:59       ` David Woodhouse
2008-06-04  9:10         ` [linux-pm] " Johannes Berg
2008-06-04  9:17           ` David Woodhouse
2008-06-04 10:51             ` Johannes Berg
2008-06-04 11:43       ` Alan Cox
2008-06-04  8:56     ` David Woodhouse
2008-06-03 10:45   ` [patch 2.6.26-rc4-git] PM: boot time suspend selftest Andy Whitcroft
2008-07-07  4:12   ` David Brownell
2008-07-23  8:19 ` Andrew Morton

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=20080530105948.GA12236@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=pavel@suse.cz \
    /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