suspend/resume debugging: device filter

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 ;-)

Signed-off-by Ingo Molnar <[email protected]>

---
 drivers/base/power/resume.c  |    6 ++++
 drivers/base/power/suspend.c |    3 +-
 include/linux/resume-trace.h |    6 ++++
 kernel/power/main.c          |   58 +++++++++++++++++++++++++++++++++++++++++++

Subject: [patch] suspend/resume debugging: device filter
From: Ingo Molnar <[email protected]>

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.)

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 ;-)

Subject: [patch] suspend/resume debugging: device filter
From: Ingo Molnar <[email protected]>

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.)

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 ;-)

Quoted 3 lines

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 ;-)

Here's a (compile tested only) patch that does this on a per-device basis, which is smaller, and should work just as well as your patch.

It creates a new file in the power/ directory for every device called "can_suspend". Write a '0' to it to prevent that device from being suspended.

drivers/base/power/sysfs.c +8 -0

+static ssize_t can_suspend_store(struct device *dev,
+				 struct device_attribute *attr,
+				 const char *buf, size_t n)
+{
+	if (!n)
+		return -EINVAL;
+
+	switch (buf[0]) {

Here's a (compile tested only) patch that does this on a per-device basis, which is smaller, and should work just as well as your patch.

It creates a new file in the power/ directory for every device called "can_suspend". Write a '0' to it to prevent that device from being suspended.

Does this work for you?

Quoted 8 lines · Greg KH

Here's a (compile tested only) patch that does this on a per-device basis, which is smaller, and should work just as well as your patch.

It creates a new file in the power/ directory for every device called "can_suspend". Write a '0' to it to prevent that device from being suspended.

Does this work for you?

yeah, i was able to use this too to debug suspend/resume problems. But i've added the check to the resume path too - for example sw-suspend does a resume of devices during its suspend cycle, cutting off much of the netconsole output.

which makes the can_suspend flag mis-named - perhaps rename it to exclude_pm ?

updated patch below, against v2.6.21. Could we get this into v2.6.22 please? It's a real time-saver.

Quoted 8 lines

Here's a (compile tested only) patch that does this on a per-device basis, which is smaller, and should work just as well as your patch.

It creates a new file in the power/ directory for every device called "can_suspend". Write a '0' to it to prevent that device from being suspended.

Does this work for you?

yeah, i was able to use this too to debug suspend/resume problems. But i've added the check to the resume path too - for example sw-suspend does a resume of devices during its suspend cycle, cutting off much of the netconsole output.

which makes the can_suspend flag mis-named - perhaps rename it to exclude_pm ?

Hi!

Quoted 14 lines

Quoted 8 lines

Here's a (compile tested only) patch that does this on a per-device basis, which is smaller, and should work just as well as your patch.

It creates a new file in the power/ directory for every device called "can_suspend". Write a '0' to it to prevent that device from being suspended.

Does this work for you?

yeah, i was able to use this too to debug suspend/resume problems. But i've added the check to the resume path too - for example sw-suspend does a resume of devices during its suspend cycle, cutting off much of the netconsole output.

Quoted 2 lines

which makes the can_suspend flag mis-named - perhaps rename it to exclude_pm ?

debug_exclude_pm? I do not want people playing with it, then complaining that they broke the suspend.