Skip to contentSkip to conversation

suspend debugging: simulate suspend-to-RAM

PATCH In review Ingo Molnar 6 participants 10 messages Jan 25, 2007 – Jan 31, 2007

Subsystems (3)
Documentation ACPI Proc sysctl
lore
Share & tools
lore

Ingo Molnar

author
#0 lore raw

PATCH 1/1 suspend debugging: simulate suspend-to-RAM

Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <[email protected]>

most resume bugs are due to the kernel hanging or crashing while trying to resume a specific device. It is extremely hard to debug such hangs because often when the hang happens there's no console available yet.

Make debugging such bugs easier by offering a resume mode that does not actually call into the BIOS to turn off the machine. This, in combination with earlyprintk=serial,ttyS0,115200,keep , CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and /sys/power/filter enables me to have a fully functional serial console during the full suspend/resume cycle.

I debugged two suspend bugs in the -rt kernel this way already, so it's pretty useful.

Signed-off-by Ingo Molnar <[email protected]>
---
 Documentation/kernel-parameters.txt |    4 ++++
 drivers/acpi/sleep/main.c           |   15 ++++++++++++++-
 include/linux/acpi.h                |    1 +
 kernel/sysctl.c                     |   16 ++++++++++++++++
 4 files changed, 35 insertions(+), 1 deletion(-)
Documentation/kernel-parameters.txt +4 -0
Index: linux/Documentation/kernel-parameters.txt
===================================================================
@@ -159,6 +159,10 @@ and is between 256 and 4096 characters. 
 
 	acpi_osi=	[HW,ACPI] empty param disables _OSI
 
+	acpi_simulate_suspend_to_ram
+			[KNL] Do not call into BIOS to do suspend-to-RAM
+			Format: <0/1>
+
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
 	acpi_skip_timer_override [HW,ACPI]
drivers/acpi/sleep/main.c +14 -1
Index: linux/drivers/acpi/sleep/main.c
===================================================================
@@ -35,6 +35,14 @@ static u32 acpi_suspend_states[] = {
 
 static int init_8259A_after_S1;
 
+/*
+ * simulate entry into the BIOS - this way the system will not
+ * be turned off for real, and the kernel's resume functionality
+ * can be debugged while still having some system capabilities
+ * left. This is especially useful in combination with /sys/power/filter.
+ */
+int acpi_simulate_suspend_to_ram;
+
 /**
  *	acpi_pm_prepare - Do preliminary suspend work.
  *	@pm_state:		suspend state we're entering.

@@ -91,7 +99,12 @@ static int acpi_pm_enter(suspend_state_t
 		break;
 
 	case PM_SUSPEND_MEM:
-		do_suspend_lowlevel();
+		if (unlikely(acpi_simulate_suspend_to_ram)) {
+			printk(KERN_INFO "ACPI: simulating suspend-to-RAM: "
+					 "not calling BIOS.\n");
+		} else {
+			do_suspend_lowlevel();
+		}
 		break;
 
 	case PM_SUSPEND_DISK:
include/linux/acpi.h +1 -0
Index: linux/include/linux/acpi.h
===================================================================
@@ -438,6 +438,7 @@ extern int pci_mmcfg_config_num;
 
 extern int sbf_port;
 extern unsigned long acpi_video_flags;
+extern int acpi_simulate_suspend_to_ram;
 
 #else	/* !CONFIG_ACPI */
kernel/sysctl.c +16 -0
Index: linux/kernel/sysctl.c
===================================================================
@@ -329,6 +329,14 @@ static ctl_table kern_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 	{
+		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "futex_performance_hack",
+		.data		= &futex_performance_hack,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
 		.ctl_name	= KERN_PANIC,
 		.procname	= "prof_pid",
 		.data		= &prof_pid,

@@ -908,6 +916,14 @@ static ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_doulongvec_minmax,
 	},
+	{
+		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "acpi_simulate_suspend_to_ram",
+		.data		= &acpi_simulate_suspend_to_ram,
+		.maxlen		= sizeof (int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 #endif
 #ifdef CONFIG_IA64
 	{
#1 lore raw

Hi!

Quoted 7 lines

Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <[email protected]>

most resume bugs are due to the kernel hanging or crashing while trying to resume a specific device. It is extremely hard to debug such hangs because often when the hang happens there's no console available yet.

While the functionality is useful, no I do not think this should be configured by sysctl or kernel parameter.

Perhaps right interface is "echo fake-mem > /sys/power/state"?

Pavel

Quoted 9 lines

Index: linux/kernel/sysctl.c
===================================================================

kernel/sysctl.c +1 -0
@@ -329,6 +329,14 @@ static ctl_table kern_table[] = {
 		.proc_handler	= &proc_dointvec,
 	},
 	{
+		.ctl_name	= CTL_UNNUMBERED,

kernel/sysctl.c static ctl_table kern_table[] = { · line 342

Quoted 10 lines
kernel/sysctl.c +7 -0
+		.procname	= "futex_performance_hack",
+		.data		= &futex_performance_hack,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
+	{
 		.ctl_name	= KERN_PANIC,
 		.procname	= "prof_pid",
 		.data		= &prof_pid,

Leftover hunk?

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#2 lore raw
Quoted 10 lines · Pavel Machek

Hi!

Quoted 7 lines

Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <[email protected]>

most resume bugs are due to the kernel hanging or crashing while trying to resume a specific device. It is extremely hard to debug such hangs because often when the hang happens there's no console available yet.

Quoted 4 lines

While the functionality is useful, no I do not think this should be configured by sysctl or kernel parameter.

Perhaps right interface is "echo fake-mem > /sys/power/state"?

Yes, the "test" and "testproc" debug modes are started via /sys/power/state, so let's make it consistent.

Greetings,
Rafael

#3 lore raw
Quoted 11 lines · Rafael J. Wysocki
Quoted 10 lines · Pavel Machek

Hi!

Quoted 7 lines

Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <[email protected]>

most resume bugs are due to the kernel hanging or crashing while trying to resume a specific device. It is extremely hard to debug such hangs because often when the hang happens there's no console available yet.

Quoted 7 lines
Quoted 4 lines

While the functionality is useful, no I do not think this should be configured by sysctl or kernel parameter.

Perhaps right interface is "echo fake-mem > /sys/power/state"?

Yes, the "test" and "testproc" debug modes are started via /sys/power/state, so let's make it consistent.

Ok, so this one should be "testmem".
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#4 lore raw
In reply to Ingo Molnar
Quoted 7 lines · Ingo Molnar

Make debugging such bugs easier by offering a resume mode that does not actually call into the BIOS to turn off the machine. This, in combination with earlyprintk=serial,ttyS0,115200,keep , CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and /sys/power/filter enables me to have a fully functional serial console during the full suspend/resume cycle.

Will it work with netconsole too? COM port is often missing in notebooks today.

-andrey

#5 lore raw
Quoted 11 lines · Andrey Borzenkov
Quoted 7 lines · Ingo Molnar

Make debugging such bugs easier by offering a resume mode that does not actually call into the BIOS to turn off the machine. This, in combination with earlyprintk=serial,ttyS0,115200,keep , CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and /sys/power/filter enables me to have a fully functional serial console during the full suspend/resume cycle.

Will it work with netconsole too? COM port is often missing in notebooks today.

Should, if you add your network device to the aforementioned filter.

Signature · 1 line
Mathematics is the supreme nostalgia of our time.
#6 lore raw
Quoted 10 lines · Matt Mackall
Quoted 9 lines · Andrey Borzenkov
Quoted 7 lines · Ingo Molnar

Make debugging such bugs easier by offering a resume mode that does not actually call into the BIOS to turn off the machine. This, in combination with earlyprintk=serial,ttyS0,115200,keep , CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and /sys/power/filter enables me to have a fully functional serial console during the full suspend/resume cycle.

Quoted 4 lines
Quoted 2 lines

Will it work with netconsole too? COM port is often missing in notebooks today.

Should, if you add your network device to the aforementioned filter.

Hm, what about the bus to which the device is connected?

Rafael

Signature · 3 lines
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King
#7 lore raw
In reply to Andrey Borzenkov
Quoted 2 lines · Andrey Borzenkov

Will it work with netconsole too? COM port is often missing in notebooks today.

It will work with some luck with firescope (in the worst case you might need to disable suspend in ochi1394). Many laptops have firewire ports.

ftp://ftp.firstfloor.org/pub/ak/firescope/

-Andi

author
#8 lore raw
Quoted 10 lines · Andi Kleen
Quoted 2 lines · Andrey Borzenkov

Will it work with netconsole too? COM port is often missing in notebooks today.

It will work with some luck with firescope (in the worst case you might need to disable suspend in ochi1394). Many laptops have firewire ports.

ftp://ftp.firstfloor.org/pub/ak/firescope/

wow, that's really neat!

Ingo

#9 lore raw
Quoted 8 lines · Ingo Molnar
Quoted 5 lines · Andi Kleen
Quoted 2 lines · Andrey Borzenkov

Will it work with netconsole too? COM port is often missing in notebooks today.

Quoted 7 lines
Quoted 5 lines

It will work with some luck with firescope (in the worst case you might need to disable suspend in ochi1394). Many laptops have firewire ports.

ftp://ftp.firstfloor.org/pub/ak/firescope/

wow, that's really neat!

To give proper credit firescope originally came from Ben Herrenschmidt for PPC. I just ported it to x86 with a few changes.

BTW if you like firescope you might also like fireproxy
http://www.suse.de/~bk/firewire/

There's also a early ohci1394 driver in there to make firescope/fireproxy work earlier during boot, but it's still somewhat experimental.

-Andi