All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	Greg KH <gregkh@suse.de>
Subject: Re: [patch] suspend/resume debugging: device filter
Date: Thu, 25 Jan 2007 12:32:33 +0100	[thread overview]
Message-ID: <20070125113233.GC23343@elf.ucw.cz> (raw)
In-Reply-To: <20070125110501.GA25151@elte.hu>

Hi!

> Subject: [patch] suspend/resume debugging: device filter
> From: Ingo Molnar <mingo@elte.hu>
> 
> this patch implements the /sys/power/filter attribute, which takes a 
> string. If a device's name matches the filter string (exactly), then 
> that device is excluded from suspend/resume.
> 
> this can be helpful in a number of ways when debugging suspend and 
> resume problems:
> 
>  - if CONFIG_DISABLE_CONSOLE_SUSPEND is used then the serial
>    console is still suspended after which point there's no
>    log output. Doing "echo serial > /sys/power/filter" keeps
>    the serial port active, so any messages (and crash info)
>    after that point is displayed.
> 
>  - if a device is suspected to be the reason of resume failure
>    then it can be excluded via the filter. That device obviously
>    wont work, but users can thus help us debug resume problems
>    in combination with pm_trace, without having to hack the kernel.
> 
> (note that you can obvious break suspend/resume via the filter, by 
> excluding a vital device - so it is only to be used when suspend or 
> resume is broken to begin with.)

Should this go to Documentation/power?

> it might be better to do this centrally in sysfs, via a per-device 
> attribute, to individually enable suspend and resume on a per device 
> basis, but my sysfs-fu is not strong enough for that now ;-)

Yep, I think it should go to per-device attribute. Also it would be
nice to name it somehow like debug_suspend_filter or something, so
that people have less tendency to play with it.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  parent reply	other threads:[~2007-01-25 11:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 11:05 [patch] suspend/resume debugging: device filter Ingo Molnar
2007-01-25 11:28 ` Nigel Cunningham
2007-01-25 11:32 ` Pavel Machek [this message]
2007-01-26  1:55 ` Greg KH
2007-01-26  1:55   ` Greg KH
2007-01-26  9:36   ` Pavel Machek
2007-01-26  9:36     ` Pavel Machek
2007-05-05  9:24   ` Ingo Molnar
2007-05-05  9:39     ` Rafael J. Wysocki
2007-05-05 10:08     ` Pavel Machek
2007-05-05 10:08       ` Pavel Machek
2007-05-08  2:54       ` [linux-pm] " Greg KH

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=20070125113233.GC23343@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@osdl.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.