Suspend and hibernation test facility

RFC PATCH In review Rafael J. Wysocki 3 participants 13 messages Nov 1, 2007 – Nov 3, 2007

Subsystems (2)

Suspend to RAM Hibernation

lore

Share & tools

lore

Rafael J. Wysocki

author

2007-11-01 22:44 UTC #0 lore raw

cover Suspend and hibernation test facility

Hi,

The following patches add a new testing facility for suspend and hibernation.

The first patch adds the possibility to test the suspend (STD) core code without actually suspending, which is useful for tracking problems with drivers etc.

The second one modifies the hibernation core so that it can use the same facility (it's a bit more powerful than the existing hibernation test modes, since they really can't test the ACPI global methods).

The third one modified documentation in accordance with the two previous ones.

Comments welcome.

Greetings,
Rafael

Signature · 1 line

"Premature optimization is the root of all evil." - Donald Knuth

Rafael J. Wysocki

author

2007-11-01 22:44 UTC #1 lore raw

RFC PATCH 1/3 Suspend: Testing facility

From: Rafael J. Wysocki <[email protected]>

Introduce /sys/power/pm_test_level attribute allowing one to test the suspend core code. Namely, writing a number (1-5) to this file causes the suspend code to work in one of the test modes defined as follows:

5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods
2 - test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of platform/system devices

Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 kernel/power/main.c  |   75 ++++++++++++++++++++++++++++++++++++++++++++-------
 kernel/power/power.h |   10 ++++++
 2 files changed, 76 insertions(+), 9 deletions(-)

kernel/power/main.c +66 -9

Index: linux-2.6/kernel/power/main.c
===================================================================
@@ -28,6 +28,46 @@ BLOCKING_NOTIFIER_HEAD(pm_chain_head);
 
 DEFINE_MUTEX(pm_mutex);
 
+#ifdef CONFIG_PM_DEBUG
+int pm_test_level = TEST_NONE;
+
+static int suspend_test(int level)
+{
+	if (pm_test_level == level) {
+		printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
+		mdelay(5000);
+		return 1;
+	}
+	return 0;
+}
+
+static ssize_t pm_test_level_show(struct kset *kset, char *buf)
+{
+	return sprintf(buf, "%d\n", pm_test_level);
+}
+
+static ssize_t
+pm_test_level_store(struct kset *kset, const char *buf, size_t n)
+{
+	int val;
+
+	if (sscanf(buf, "%d", &val) != 1)
+		return -EINVAL;
+
+	if (val < TEST_NONE || val > TEST_FREEZER)
+		return -EINVAL;
+
+	pm_test_level = val;
+
+	return n;
+}
+
+power_attr(pm_test_level);
+#else /* !CONFIG_PM_DEBUG */
+static inline int suspend_test(int level) { return 0; }
+#endif /* !CONFIG_PM_DEBUG */
+
+
 #ifdef CONFIG_SUSPEND
 
 /* This is just an arbitrary number */

@@ -133,7 +173,10 @@ static int suspend_enter(suspend_state_t
 		printk(KERN_ERR "Some devices failed to power down\n");
 		goto Done;
 	}
-	error = suspend_ops->enter(state);
+
+	if (!suspend_test(TEST_CORE))
+		error = suspend_ops->enter(state);
+
 	device_power_up();
  Done:
 	arch_suspend_enable_irqs();

@@ -164,16 +207,25 @@ int suspend_devices_and_enter(suspend_st
 		printk(KERN_ERR "Some devices failed to suspend\n");
 		goto Resume_console;
 	}
+
+	if (suspend_test(TEST_DEVICES))
+		goto Resume_devices;
+
 	if (suspend_ops->prepare) {
 		error = suspend_ops->prepare();
 		if (error)
 			goto Resume_devices;
 	}
+
+	if (suspend_test(TEST_PLATFORM))
+		goto Finish;
+
 	error = disable_nonboot_cpus();
-	if (!error)
+	if (!error && !suspend_test(TEST_CPUS))
 		suspend_enter(state);
 
 	enable_nonboot_cpus();
+ Finish:
 	if (suspend_ops->finish)
 		suspend_ops->finish();
  Resume_devices:

@@ -240,12 +292,17 @@ static int enter_state(suspend_state_t s
 	printk("done.\n");
 
 	pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
-	if ((error = suspend_prepare()))
+	error = suspend_prepare();
+	if (error)
 		goto Unlock;
 
+	if (suspend_test(TEST_FREEZER))
+		goto Finish;
+
 	pr_debug("PM: Entering %s sleep\n", pm_states[state]);
 	error = suspend_devices_and_enter(state);
 
+ Finish:
 	pr_debug("PM: Finishing wakeup.\n");
 	suspend_finish();
  Unlock:

@@ -363,18 +420,18 @@ pm_trace_store(struct kset *kset, const 
 }
 
 power_attr(pm_trace);
+#endif /* CONFIG_PM_TRACE */
 
 static struct attribute * g[] = {
 	&state_attr.attr,
+#ifdef CONFIG_PM_TRACE
 	&pm_trace_attr.attr,
+#endif
+#ifdef CONFIG_PM_DEBUG
+	&pm_test_level_attr.attr,
+#endif
 	NULL,
 };
-#else
-static struct attribute * g[] = {
-	&state_attr.attr,
-	NULL,
-};
-#endif /* CONFIG_PM_TRACE */
 
 static struct attribute_group attr_group = {
 	.attrs = g,

kernel/power/power.h +10 -0

Index: linux-2.6/kernel/power/power.h
===================================================================
@@ -182,3 +182,13 @@ static inline int pm_notifier_call_chain
 	return (blocking_notifier_call_chain(&pm_chain_head, val, NULL)
 			== NOTIFY_BAD) ? -EINVAL : 0;
 }
+
+/* Suspend test levels */
+enum {
+	TEST_NONE,
+	TEST_CORE,
+	TEST_CPUS,
+	TEST_PLATFORM,
+	TEST_DEVICES,
+	TEST_FREEZER
+};

Johannes Berg

2007-11-02 10:32 UTC #2 lore raw

Re: [linux-pm] [RFC][PATCH 1/3] Suspend: Testing facility

kernel/power/power.h static inline int pm_notifier_call_chain · line 188

Quoted 7 lines

5 - test the freezing of processes
kernel/power/power.h +3 -0
+/* Suspend test levels */
+enum {
+	TEST_NONE,

Without reading the code, I assume that this enum controls those levels. I think a comment that it is user-space visible API and should not be reordered would be warranted.

johannes

Rafael J. Wysocki

author

2007-11-02 10:47 UTC #3 lore raw

Re: [linux-pm] [RFC][PATCH 1/3] Suspend: Testing facility

Quoted 10 lines · Johannes Berg

kernel/power/power.h static inline int pm_notifier_call_chain · line 188
Quoted 6 lines
5 - test the freezing of processes
kernel/power/power.h +3 -0
+/* Suspend test levels */
+enum {
+	TEST_NONE,
Without reading the code, I assume that this enum controls those levels. I think a comment that it is user-space visible API and should not be reordered would be warranted.

Yes, you are right. I'll add the comment.

Thanks,
Rafael

Rafael J. Wysocki

author

2007-11-02 11:04 UTC #4 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

In reply to Johannes Berg

Quoted 10 lines · Johannes Berg

kernel/power/power.h static inline int pm_notifier_call_chain · line 188
Quoted 6 lines
5 - test the freezing of processes
kernel/power/power.h +3 -0
+/* Suspend test levels */
+enum {
+	TEST_NONE,
Without reading the code, I assume that this enum controls those levels. I think a comment that it is user-space visible API and should not be reordered would be warranted.

Yes, you are right. I'll add the comment.

Thanks,
Rafael

Johannes Berg

2007-11-02 10:33 UTC #5 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

In reply to Rafael J. Wysocki

kernel/power/power.h static inline int pm_notifier_call_chain · line 188

Quoted 7 lines

5 - test the freezing of processes
kernel/power/power.h +3 -0
+/* Suspend test levels */
+enum {
+	TEST_NONE,

Without reading the code, I assume that this enum controls those levels. I think a comment that it is user-space visible API and should not be reordered would be warranted.

johannes

Pavel Machek

2007-11-03 18:23 UTC #6 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

In reply to Rafael J. Wysocki

Hi!

Quoted 19 lines

Introduce /sys/power/pm_test_level attribute allowing one to test the suspend core code. Namely, writing a number (1-5) to this file causes the suspend code to work in one of the test modes defined as follows:
5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods
2 - test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of platform/system devices
Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Quoted 4 lines

Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .
Signed-off-by Rafael J. Wysocki <[email protected]>

ACK on whole series, but... should we also remove the old debugging infrastructure? (Or did I just miss it?)
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2007-11-03 18:23 UTC #7 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

In reply to Rafael J. Wysocki

Hi!

Quoted 19 lines

Introduce /sys/power/pm_test_level attribute allowing one to test the suspend core code. Namely, writing a number (1-5) to this file causes the suspend code to work in one of the test modes defined as follows:
5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods
2 - test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of platform/system devices
Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Quoted 4 lines

Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .
Signed-off-by Rafael J. Wysocki <[email protected]>

ACK on whole series, but... should we also remove the old debugging infrastructure? (Or did I just miss it?)
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Rafael J. Wysocki

author

2007-11-03 18:37 UTC #8 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

Hi,

Quoted 21 lines · Pavel Machek

Hi!
Quoted 19 lines
Introduce /sys/power/pm_test_level attribute allowing one to test the suspend core code. Namely, writing a number (1-5) to this file causes the suspend code to work in one of the test modes defined as follows:
5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods
2 - test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of platform/system devices
Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Quoted 7 lines

Quoted 4 lines
Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .
Signed-off-by Rafael J. Wysocki <[email protected]>
ACK on whole series, but... should we also remove the old debugging infrastructure? (Or did I just miss it?)

Well, I don't want to remove it just yet, but it's going to be deprecated.

Also, after Johannes' remark I thought it wouldn't be a good idea to export the bare test levels to the user. For this reason I reworked the patches to use strings instead of numbers for the test setting (the attribute is now called "pm_test" and is used in a similar way to "disk").

I'll post the reworked series as soon as I update the changelogs and docs.

Greetings,
Rafael

Rafael J. Wysocki

author

2007-11-03 18:54 UTC #9 lore raw

Re: [RFC][PATCH 1/3] Suspend: Testing facility

In reply to Pavel Machek

Hi,

Quoted 21 lines · Pavel Machek

Hi!
Quoted 19 lines
Introduce /sys/power/pm_test_level attribute allowing one to test the suspend core code. Namely, writing a number (1-5) to this file causes the suspend code to work in one of the test modes defined as follows:
5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods
2 - test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of platform/system devices
Then, if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Quoted 7 lines

Quoted 4 lines
Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .
Signed-off-by Rafael J. Wysocki <[email protected]>
ACK on whole series, but... should we also remove the old debugging infrastructure? (Or did I just miss it?)

Well, I don't want to remove it just yet, but it's going to be deprecated.

I'll post the reworked series as soon as I update the changelogs and docs.

Greetings,
Rafael

Rafael J. Wysocki

author

2007-11-01 22:58 UTC #10 lore raw

RFC PATCH 1/3 Suspend: Testing facility

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

Writing 0 to /sys/power/pm_test_level turns the testing off. The current test level may be read from /sys/power/pm_test_level .

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 kernel/power/main.c  |   75 ++++++++++++++++++++++++++++++++++++++++++++-------
 kernel/power/power.h |   10 ++++++
 2 files changed, 76 insertions(+), 9 deletions(-)

kernel/power/main.c +66 -9

Index: linux-2.6/kernel/power/main.c
===================================================================
@@ -28,6 +28,46 @@ BLOCKING_NOTIFIER_HEAD(pm_chain_head);
 
 DEFINE_MUTEX(pm_mutex);
 
+#ifdef CONFIG_PM_DEBUG
+int pm_test_level = TEST_NONE;
+
+static int suspend_test(int level)
+{
+	if (pm_test_level == level) {
+		printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
+		mdelay(5000);
+		return 1;
+	}
+	return 0;
+}
+
+static ssize_t pm_test_level_show(struct kset *kset, char *buf)
+{
+	return sprintf(buf, "%d\n", pm_test_level);
+}
+
+static ssize_t
+pm_test_level_store(struct kset *kset, const char *buf, size_t n)
+{
+	int val;
+
+	if (sscanf(buf, "%d", &val) != 1)
+		return -EINVAL;
+
+	if (val < TEST_NONE || val > TEST_FREEZER)
+		return -EINVAL;
+
+	pm_test_level = val;
+
+	return n;
+}
+
+power_attr(pm_test_level);
+#else /* !CONFIG_PM_DEBUG */
+static inline int suspend_test(int level) { return 0; }
+#endif /* !CONFIG_PM_DEBUG */
+
+
 #ifdef CONFIG_SUSPEND
 
 /* This is just an arbitrary number */

@@ -133,7 +173,10 @@ static int suspend_enter(suspend_state_t
 		printk(KERN_ERR "Some devices failed to power down\n");
 		goto Done;
 	}
-	error = suspend_ops->enter(state);
+
+	if (!suspend_test(TEST_CORE))
+		error = suspend_ops->enter(state);
+
 	device_power_up();
  Done:
 	arch_suspend_enable_irqs();

@@ -164,16 +207,25 @@ int suspend_devices_and_enter(suspend_st
 		printk(KERN_ERR "Some devices failed to suspend\n");
 		goto Resume_console;
 	}
+
+	if (suspend_test(TEST_DEVICES))
+		goto Resume_devices;
+
 	if (suspend_ops->prepare) {
 		error = suspend_ops->prepare();
 		if (error)
 			goto Resume_devices;
 	}
+
+	if (suspend_test(TEST_PLATFORM))
+		goto Finish;
+
 	error = disable_nonboot_cpus();
-	if (!error)
+	if (!error && !suspend_test(TEST_CPUS))
 		suspend_enter(state);
 
 	enable_nonboot_cpus();
+ Finish:
 	if (suspend_ops->finish)
 		suspend_ops->finish();
  Resume_devices:

@@ -240,12 +292,17 @@ static int enter_state(suspend_state_t s
 	printk("done.\n");
 
 	pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
-	if ((error = suspend_prepare()))
+	error = suspend_prepare();
+	if (error)
 		goto Unlock;
 
+	if (suspend_test(TEST_FREEZER))
+		goto Finish;
+
 	pr_debug("PM: Entering %s sleep\n", pm_states[state]);
 	error = suspend_devices_and_enter(state);
 
+ Finish:
 	pr_debug("PM: Finishing wakeup.\n");
 	suspend_finish();
  Unlock:

@@ -363,18 +420,18 @@ pm_trace_store(struct kset *kset, const 
 }
 
 power_attr(pm_trace);
+#endif /* CONFIG_PM_TRACE */
 
 static struct attribute * g[] = {
 	&state_attr.attr,
+#ifdef CONFIG_PM_TRACE
 	&pm_trace_attr.attr,
+#endif
+#ifdef CONFIG_PM_DEBUG
+	&pm_test_level_attr.attr,
+#endif
 	NULL,
 };
-#else
-static struct attribute * g[] = {
-	&state_attr.attr,
-	NULL,
-};
-#endif /* CONFIG_PM_TRACE */
 
 static struct attribute_group attr_group = {
 	.attrs = g,

kernel/power/power.h +10 -0

Index: linux-2.6/kernel/power/power.h
===================================================================
@@ -182,3 +182,13 @@ static inline int pm_notifier_call_chain
 	return (blocking_notifier_call_chain(&pm_chain_head, val, NULL)
 			== NOTIFY_BAD) ? -EINVAL : 0;
 }
+
+/* Suspend test levels */
+enum {
+	TEST_NONE,
+	TEST_CORE,
+	TEST_CPUS,
+	TEST_PLATFORM,
+	TEST_DEVICES,
+	TEST_FREEZER
+};

Rafael J. Wysocki

author

2007-11-01 22:44 UTC #11 lore raw

RFC PATCH 2/3 Hibernation: New testing facility

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

Make it possible to test the hibernation core code with the help of the /sys/power/pm_test_level attribute introduced for suspend testing in the previous patch.

Writing a number (1-5) to this file causes the hibernation code to work in one of the test modes defined as follows:

5 - test the freezing of processes
4 - test the freezing of processes and suspending of devices
3 - test the freezing of processes, suspending of devices and platform global
control methods(*)
2 - test the freezing of processes, suspending of devices, platform global
control methods(*) and the disabling of nonboot CPUs
1 - test the freezing of processes, suspending of devices, platform global
control methods(*), the disabling of nonboot CPUs and suspending of platform/system devices

(*) - the platform global control methods are only available on ACPI systems
and are only tested if the hibernation mode is set to "platform"

Then, if a hibernation is started by normal means, the hibernation core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state.

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 kernel/power/disk.c  |   70 ++++++++++++++++++++++++++++++++++++++++-----------
 kernel/power/power.h |    2 +
 2 files changed, 57 insertions(+), 15 deletions(-)

kernel/power/disk.c +55 ~~-15~~

Index: linux-2.6/kernel/power/disk.c
===================================================================
@@ -70,6 +70,35 @@ void hibernation_set_ops(struct platform
 	mutex_unlock(&pm_mutex);
 }
 
+#ifdef CONFIG_PM_DEBUG
+static void hibernation_debug_sleep(void)
+{
+	printk(KERN_INFO "hibernation debug: Waiting for 5 seconds.\n");
+	mdelay(5000);
+}
+
+static int hibernation_testmode(int mode)
+{
+	if (hibernation_mode == mode) {
+		hibernation_debug_sleep();
+		return 1;
+	}
+	return 0;
+}
+
+static int hibernation_test(int level)
+{
+	if (pm_test_level == level) {
+		hibernation_debug_sleep();
+		return 1;
+	}
+	return 0;
+}
+#else /* !CONFIG_PM_DEBUG */
+static int hibernation_testmode(int mode) { return 0; }
+static int hibernation_test(int level) { return 0; }
+#endif /* !CONFIG_PM_DEBUG */
+
 /**
  *	platform_start - tell the platform driver that we're starting
  *	hibernation

@@ -167,6 +196,10 @@ int create_image(int platform_mode)
 		goto Enable_irqs;
 	}
 
+	if (hibernation_test(TEST_CORE))
+		goto Power_up;
+
+	in_suspend = 1;
 	save_processor_state();
 	error = swsusp_arch_suspend();
 	if (error)

@@ -175,6 +208,7 @@ int create_image(int platform_mode)
 	restore_processor_state();
 	if (!in_suspend)
 		platform_leave(platform_mode);
+ Power_up:
 	/* NOTE:  device_power_up() is just a resume() for devices
 	 * that suspended with irqs off ... no overall powerup.
 	 */

@@ -211,24 +245,29 @@ int hibernation_snapshot(int platform_mo
 	if (error)
 		goto Resume_console;
 
-	error = platform_pre_snapshot(platform_mode);
-	if (error)
+	if (hibernation_test(TEST_DEVICES))
 		goto Resume_devices;
 
+	error = platform_pre_snapshot(platform_mode);
+	if (error || hibernation_test(TEST_PLATFORM))
+		goto Finish;
+
 	error = disable_nonboot_cpus();
 	if (!error) {
-		if (hibernation_mode != HIBERNATION_TEST) {
-			in_suspend = 1;
-			error = create_image(platform_mode);
-			/* Control returns here after successful restore */
-		} else {
-			printk("swsusp debug: Waiting for 5 seconds.\n");
-			mdelay(5000);
-		}
+		if (hibernation_test(TEST_CPUS))
+			goto Enable_cpus;
+
+		if (hibernation_testmode(HIBERNATION_TEST))
+			goto Enable_cpus;
+
+		error = create_image(platform_mode);
+		/* Control returns here after successful restore */
 	}
+ Enable_cpus:
 	enable_nonboot_cpus();
- Resume_devices:
+ Finish:
 	platform_finish(platform_mode);
+ Resume_devices:
 	device_resume();
  Resume_console:
 	resume_console();

@@ -406,11 +445,12 @@ int hibernate(void)
 	if (error)
 		goto Finish;
 
-	if (hibernation_mode == HIBERNATION_TESTPROC) {
-		printk("swsusp debug: Waiting for 5 seconds.\n");
-		mdelay(5000);
+	if (hibernation_test(TEST_FREEZER))
 		goto Thaw;
-	}
+
+	if (hibernation_testmode(HIBERNATION_TESTPROC))
+		goto Thaw;
+
 	error = hibernation_snapshot(hibernation_mode == HIBERNATION_PLATFORM);
 	if (in_suspend && !error) {
 		unsigned int flags = 0;

kernel/power/power.h +2 -0

Index: linux-2.6/kernel/power/power.h
===================================================================
@@ -192,3 +192,5 @@ enum {
 	TEST_DEVICES,
 	TEST_FREEZER
 };
+
+extern int pm_test_level;

Rafael J. Wysocki

author

2007-11-01 22:44 UTC #12 lore raw

RFC PATCH 3/3 PM: Suspend/hibernation debug documentation update

In reply to Rafael J. Wysocki

From: Rafael J. Wysocki <[email protected]>

Update the suspend/hibernation debugging and testing documentation to describe the newly introduced testing facilities.

Signed-off-by Rafael J. Wysocki <[email protected]>

---
 Documentation/power/basic-pm-debugging.txt |  188 ++++++++++++++++++++---------
 Documentation/power/drivers-testing.txt    |   28 ++--
 2 files changed, 149 insertions(+), 67 deletions(-)

Documentation/power/drivers-testing.txt +16 ~~-12~~

Index: linux-2.6/Documentation/power/drivers-testing.txt
===================================================================
@@ -6,9 +6,9 @@ Testing suspend and resume support in de
 Unfortunately, to effectively test the support for the system-wide suspend and
 resume transitions in a driver, it is necessary to suspend and resume a fully
 functional system with this driver loaded.  Moreover, that should be done
-several times, preferably several times in a row, and separately for the suspend
-to disk (STD) and the suspend to RAM (STR) transitions, because each of these
-cases involves different ordering of operations and different interactions with
+several times, preferably several times in a row, and separately for hibernation
+(aka suspend to disk or STD) and suspend to RAM (STR), because each of these
+cases involves slightly different operations and different interactions with
 the machine's BIOS.
 
 Of course, for this purpose the test system has to be known to suspend and

@@ -22,20 +22,24 @@ for more information about the debugging
 Once you have resolved the suspend/resume-related problems with your test system
 without the new driver, you are ready to test it:
 
-a) Build the driver as a module, load it and try the STD in the test mode (see:
-Documents/power/basic-pm-debugging.txt, 1a)).
+a) Build the driver as a module, load it and try the test modes of hibernation
+(see: Documents/power/basic-pm-debugging.txt, 1)).
 
-b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"
-and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
+b) Load the driver and attempt to hibernate in the "reboot", "shutdown" and
+"platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
 
-c) Compile the driver directly into the kernel and try the STD in the test mode.
+c) Compile the driver directly into the kernel and try the test modes of
+hibernation.
 
-d) Attempt to suspend to disk with the driver compiled directly into the kernel
+d) Attempt to hibernate with the driver compiled directly into the kernel
 in the "reboot", "shutdown" and "platform" modes.
 
-e) Attempt to suspend to RAM using the s2ram tool with the driver loaded (see:
-Documents/power/basic-pm-debugging.txt, 2).  As far as the STR tests are
-concerned, it should not matter whether or not the driver is built as a module.
+e) Try the test modes of suspend (see: Documents/power/basic-pm-debugging.txt,
+2)).  [As far as the STR tests are concerned, it should not matter whether or
+not the driver is built as a module.]
+
+f) Attempt to suspend to RAM using the s2ram tool with the driver loaded
+(see: Documents/power/basic-pm-debugging.txt, 2).
 
 Each of the above tests should be repeated several times and the STD tests
 should be mixed with the STR tests.  If any of them fails, the driver cannot be

Documentation/power/basic-pm-debugging.txt +133 ~~-55~~

235 lines not on this page · raw message