[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070125113233.GC23343@elf.ucw.cz>
Date: Thu, 25 Jan 2007 12:32:33 +0100
From: Pavel Machek <pavel@....cz>
To: Ingo Molnar <mingo@...e.hu>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...l.org>, Greg KH <gregkh@...e.de>
Subject: Re: [patch] suspend/resume debugging: device filter
Hi!
> Subject: [patch] suspend/resume debugging: device filter
> From: Ingo Molnar <mingo@...e.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
-
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