[PATCH] s4bios for 2.5.59 + apci-20030123

[PATCH] s4bios for 2.5.59 + apci-20030123

[Ducrot Bruno]

Hi Andy,

This patch is for s4bios support in 2.5.59 with acpi-20030123.

This is the 'minimal' requirement.  Some devices (especially the
IDE part) are not well resumed.  Handle with care..

Note also that the resuming part (I mean IDE) was more stable
with an equivalent patch when I tested with 2.5.54 (grumble grumble)...

I think also that it is a 'good' checker for devices power management
in general...




 arch/i386/kernel/acpi_wakeup.S  |   35 ++++++++++++++++++++++++++-----
 drivers/acpi/acpi_ksyms.c       |    1 
 drivers/acpi/hardware/hwsleep.c |   45 ++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/sleep.c            |   39 ++++++++++++++++++++++++++++++----
 include/acpi/acpixf.h           |    4 +++
 include/linux/suspend.h         |    1 
 6 files changed, 115 insertions(+), 10 deletions(-)


--- linux-2.5.59-acpi-20030123/arch/i386/kernel/acpi_wakeup.S	2003/01/31 15:37:05	1.1
+++ linux-2.5.59-acpi-20030123/arch/i386/kernel/acpi_wakeup.S	2003/01/31 16:33:25
@@ -160,9 +160,9 @@
 	ALIGN
 
 
-.org	0x2000
+.org	0x800
 wakeup_stack:
-.org	0x3000
+.org	0x900
 ENTRY(wakeup_end)
 .org	0x4000
 
@@ -274,7 +274,7 @@
 
 ENTRY(do_suspend_lowlevel)
 	cmpl $0,4(%esp)
-	jne .L1432
+	jne ret_point
 	call save_processor_state
 
 	movl %esp, saved_context_esp
@@ -287,7 +287,7 @@
 	movl %edi, saved_context_edi
 	pushfl ; popl saved_context_eflags
 
-	movl $.L1432,saved_eip
+	movl $ret_point,saved_eip
 	movl %esp,saved_esp
 	movl %ebp,saved_ebp
 	movl %ebx,saved_ebx
@@ -299,7 +299,7 @@
 	addl $4,%esp
 	ret
 	.p2align 4,,7
-.L1432:
+ret_point:
 	movl $__KERNEL_DS,%eax
 	movw %ax, %ds
 	movl saved_context_esp, %esp
@@ -312,6 +312,31 @@
 	movl saved_context_edi, %edi
 	call restore_processor_state
 	pushl saved_context_eflags ; popfl
+	ret
+
+ENTRY(do_suspend_lowlevel_s4bios)
+	cmpl $0,4(%esp)
+	jne ret_point
+	call save_processor_state
+
+	movl %esp, saved_context_esp
+	movl %eax, saved_context_eax
+	movl %ebx, saved_context_ebx
+	movl %ecx, saved_context_ecx
+	movl %edx, saved_context_edx
+	movl %ebp, saved_context_ebp
+	movl %esi, saved_context_esi
+	movl %edi, saved_context_edi
+	pushfl ; popl saved_context_eflags
+
+	movl $ret_point,saved_eip
+	movl %esp,saved_esp
+	movl %ebp,saved_ebp
+	movl %ebx,saved_ebx
+	movl %edi,saved_edi
+	movl %esi,saved_esi
+
+	call acpi_enter_sleep_state_s4bios
 	ret
 
 ALIGN
--- linux-2.5.59-acpi-20030123/drivers/acpi/hardware/hwsleep.c	2003/01/31 15:37:10	1.1
+++ linux-2.5.59-acpi-20030123/drivers/acpi/hardware/hwsleep.c	2003/01/31 16:37:27
@@ -316,6 +316,51 @@
 	return_ACPI_STATUS (AE_OK);
 }
 
+
+/******************************************************************************
+ *
+ * FUNCTION:    acpi_enter_sleep_state_s4bios
+ *
+ * PARAMETERS:  None
+ *
+ * RETURN:      Status
+ *
+ * DESCRIPTION: Perform a s4 bios request.
+ *              THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_enter_sleep_state_s4bios (
+	void)
+{
+	u32                     in_value;
+	acpi_status             status;
+
+
+	ACPI_FUNCTION_TRACE ("Acpi_enter_sleep_state_s4bios");
+
+	acpi_set_register (ACPI_BITREG_WAKE_STATUS, 1, ACPI_MTX_LOCK);
+	acpi_hw_clear_acpi_status();
+
+	acpi_hw_disable_non_wakeup_gpes();
+
+	ACPI_FLUSH_CPU_CACHE();
+
+	status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+	do {
+		acpi_os_stall(1000);
+		status = acpi_get_register (ACPI_BITREG_WAKE_STATUS, &in_value, ACPI_MTX_LOCK);
+		if (ACPI_FAILURE (status)) {
+			return_ACPI_STATUS (status);
+		}
+	} while (!in_value);
+ 
+ 	return_ACPI_STATUS (AE_OK);
+ }
+ 
+
 /******************************************************************************
  *
  * FUNCTION:    acpi_leave_sleep_state
--- linux-2.5.59-acpi-20030123/drivers/acpi/sleep.c	2003/01/31 15:37:19	1.1
+++ linux-2.5.59-acpi-20030123/drivers/acpi/sleep.c	2003/01/31 16:29:13
@@ -150,8 +150,10 @@
 		if (state > ACPI_STATE_S1) {
 			error = acpi_save_state_mem();
 
+#if 0
 			if (!error && (state == ACPI_STATE_S4))
 				error = acpi_save_state_disk();
+#endif
 
 			if (error) {
 				device_resume(RESUME_RESTORE_STATE);
@@ -223,11 +225,17 @@
 		status = acpi_enter_sleep_state(state);
 		break;
 
-	case ACPI_STATE_S2:
 #ifdef CONFIG_SOFTWARE_SUSPEND
+	case ACPI_STATE_S2:
 	case ACPI_STATE_S3:
 		do_suspend_lowlevel(0);
+		break;
 #endif
+	case ACPI_STATE_S4:
+		do_suspend_lowlevel_s4bios(0);
+		break;
+	default:
+		printk(KERN_WARNING PREFIX "don't know how to handle %d state.\n", state);
 		break;
 	}
 	local_irq_restore(flags);
@@ -251,10 +259,20 @@
 	if (state < ACPI_STATE_S1 || state > ACPI_STATE_S5)
 		return AE_ERROR;
 
+	/* Since we handle S4OS via a different path (swsusp), give up if no s4bios. */
+	if (state == ACPI_STATE_S4 && !acpi_gbl_FACS->S4bios_f)
+		return AE_ERROR;
+
+	/*
+	 * TBD: S1 can be done without device_suspend.  Make a CONFIG_XX
+	 * to handle however when S1 failed without device_suspend.
+	 */
 	freeze_processes();		/* device_suspend needs processes to be stopped */
 
 	/* do we have a wakeup address for S2 and S3? */
-	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3) {
+	/* Here, we support only S4BIOS, those we set the wakeup address */
+	/* S4OS is only supported for now via swsusp.. */
+	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || ACPI_STATE_S4) {
 		if (!acpi_wakeup_address)
 			return AE_ERROR;
 		acpi_set_firmware_waking_vector((acpi_physical_address) acpi_wakeup_address);
@@ -297,8 +315,11 @@
 	ACPI_FUNCTION_TRACE("acpi_system_sleep_seq_show");
 
 	for (i = 0; i <= ACPI_STATE_S5; i++) {
-		if (sleep_states[i])
+		if (sleep_states[i]) {
 			seq_printf(seq,"S%d ", i);
+			if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f)
+				seq_printf(seq, "S4bios ");
+		}
 	}
 
 	seq_puts(seq, "\n");
@@ -337,12 +358,16 @@
 	if (!sleep_states[state])
 		return_VALUE(-ENODEV);
 
+	if (state == 4 && state_string[1] != 'b') {
 #ifdef CONFIG_SOFTWARE_SUSPEND
-	if (state == 4) {
 		software_suspend();
 		return_VALUE(count);
-	}
+#else
+		printk(KERN_WARNING PREFIX "no swsusp support!?\n");
+		printk(KERN_WARNING PREFIX "Trying S4bios instead\n");
 #endif
+	}
+
 	status = acpi_suspend(state);
 
 	if (ACPI_FAILURE(status))
@@ -661,6 +686,10 @@
 		if (ACPI_SUCCESS(status)) {
 			sleep_states[i] = 1;
 			printk(" S%d", i);
+		}
+		if (i == ACPI_STATE_S4 && acpi_gbl_FACS->S4bios_f) {
+			sleep_states[i] = 1;
+			printk(" S4bios");
 		}
 	}
 	printk(")\n");
--- linux-2.5.59-acpi-20030123/drivers/acpi/acpi_ksyms.c	2003/01/31 15:37:21	1.1
+++ linux-2.5.59-acpi-20030123/drivers/acpi/acpi_ksyms.c	2003/01/31 16:29:39
@@ -86,6 +86,7 @@
 EXPORT_SYMBOL(acpi_get_register);
 EXPORT_SYMBOL(acpi_set_register);
 EXPORT_SYMBOL(acpi_enter_sleep_state);
+EXPORT_SYMBOL(acpi_enter_sleep_state_s4bios);
 EXPORT_SYMBOL(acpi_get_system_info);
 EXPORT_SYMBOL(acpi_get_devices);
 
--- linux-2.5.59-acpi-20030123/include/acpi/acpixf.h	2003/01/31 15:38:22	1.1
+++ linux-2.5.59-acpi-20030123/include/acpi/acpixf.h	2003/01/31 16:31:57
@@ -380,6 +380,10 @@
 	u8                              sleep_state);
 
 acpi_status
+acpi_enter_sleep_state_s4bios (
+	void);
+
+acpi_status
 acpi_leave_sleep_state (
 	u8                              sleep_state);
 
--- linux-2.5.59-acpi-20030123/include/linux/suspend.h	2003/01/31 15:37:22	1.1
+++ linux-2.5.59-acpi-20030123/include/linux/suspend.h	2003/01/31 16:30:28
@@ -73,6 +73,7 @@
 /* Communication between acpi and arch/i386/suspend.c */
 
 extern void do_suspend_lowlevel(int resume);
+extern void do_suspend_lowlevel_s4bios(int resume);
 
 #else
 static inline void software_suspend(void)




Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

RE: [PATCH] s4bios for 2.5.59 + apci-20030123

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] 
> This patch is for s4bios support in 2.5.59 with acpi-20030123.
> 
> This is the 'minimal' requirement.  Some devices (especially the
> IDE part) are not well resumed.  Handle with care..
> 
> Note also that the resuming part (I mean IDE) was more stable
> with an equivalent patch when I tested with 2.5.54 (grumble 
> grumble)...
> 
> I think also that it is a 'good' checker for devices power management
> in general...

I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
OS can do S4 on its own, that is really preferable to S4bios.

Regards -- Andy

Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Pavel Machek]

Hi!

> > This patch is for s4bios support in 2.5.59 with acpi-20030123.
> > 
> > This is the 'minimal' requirement.  Some devices (especially the
> > IDE part) are not well resumed.  Handle with care..
> > 
> > Note also that the resuming part (I mean IDE) was more stable
> > with an equivalent patch when I tested with 2.5.54 (grumble 
> > grumble)...
> > 
> > I think also that it is a 'good' checker for devices power management
> > in general...
> 
> I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
> OS can do S4 on its own, that is really preferable to S4bios.

Well, we already have S4OS, and having S4OS does not mean we can't
have S4bios.

Some people apparently want slower suspend/resume but have all caches
intact when resumed. Thats not easy for swsusp but they can have that
with S4bios. And S4bios is usefull for testing device support; it
seems to behave slightly differently to S3 meaning better testing.

If you already have hibernation partition from factory, which you are
using anyway for w98, S4bios is easier to use and more foolproof
(i.e. you can't boot into wrong kernel which does not resume but does
fsck instead).

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Matthew Garrett]

On Fri, Jan 31, 2003 at 06:39:04PM +0100, Ducrot Bruno wrote:

Hi Ducrot,

> This is the 'minimal' requirement.  Some devices (especially the
> IDE part) are not well resumed.  Handle with care..

Using this patch (on top of 2.5.59 and acpi 20030123), echo 4b 
>/proc/acpi/sleep results in the system freezing all of the processes 
and then resetting itself without any state change. This is an IBM 
Thinkpad 240x which claims to support S4Bios, and I have the appropriate 
partition. Would it be worth me enabling debugging and hooking up a 
serial console?

Thanks,
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Ducrot Bruno]

On Tue, Feb 04, 2003 at 11:10:04PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > This patch is for s4bios support in 2.5.59 with acpi-20030123.
> > > 
> > > This is the 'minimal' requirement.  Some devices (especially the
> > > IDE part) are not well resumed.  Handle with care..
> > > 
> > > Note also that the resuming part (I mean IDE) was more stable
> > > with an equivalent patch when I tested with 2.5.54 (grumble 
> > > grumble)...
> > > 
> > > I think also that it is a 'good' checker for devices power management
> > > in general...
> > 
> > I'd really rather just have S4OS (aka swsusp) in 2.5 patches -- if the
> > OS can do S4 on its own, that is really preferable to S4bios.
> 
> Well, we already have S4OS, and having S4OS does not mean we can't
> have S4bios.
> 
> Some people apparently want slower suspend/resume but have all caches
> intact when resumed. Thats not easy for swsusp but they can have that
> with S4bios. And S4bios is usefull for testing device support; it
> seems to behave slightly differently to S3 meaning better testing.
> 

Yep, correct.  The problem is that now I have more trouble with s4bios
in general with 2.5.  That worked more reliability with 'older' 2.5 series.
Really don't know why.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham]

On Wed, 2003-02-05 at 11:10, Pavel Machek wrote:
> Some people apparently want slower suspend/resume but have all caches
> intact when resumed. Thats not easy for swsusp but they can have that
> with S4bios. And S4bios is usefull for testing device support; it
> seems to behave slightly differently to S3 meaning better testing.

Whether its slower depends on the hardware; on my 128MB Celeron 933
laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
back up and running in around a minute and a half. That's about the same
as far as I remember, but has (as you say) the advantage of not still
having to get things swapped back in.

> 
> If you already have hibernation partition from factory, which you are
> using anyway for w98, S4bios is easier to use and more foolproof
> (i.e. you can't boot into wrong kernel which does not resume but does
> fsck instead).

It doesn't really matter what kernel is loaded when we start a resume
anyway, does it? Could they not be different versions because one is
going to replace the other anyway?

Regards,

Nigel

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Ducrot Bruno]

On Thu, Feb 06, 2003 at 09:41:44AM +1300, Nigel Cunningham wrote:
> On Wed, 2003-02-05 at 11:10, Pavel Machek wrote:
> > Some people apparently want slower suspend/resume but have all caches
> > intact when resumed. Thats not easy for swsusp but they can have that
> > with S4bios. And S4bios is usefull for testing device support; it
> > seems to behave slightly differently to S3 meaning better testing.
> 
> Whether its slower depends on the hardware; on my 128MB Celeron 933
> laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
> back up and running in around a minute and a half. That's about the same
> as far as I remember, but has (as you say) the advantage of not still
> having to get things swapped back in.

The problem is the speed of the suspending process, not the whole suspend/resume
sequence,  especially in case of emergency suspending due to thermal condition,
etc.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Pavel Machek]

Hi!

> > Some people apparently want slower suspend/resume but have all caches
> > intact when resumed. Thats not easy for swsusp but they can have that
> > with S4bios. And S4bios is usefull for testing device support; it
> > seems to behave slightly differently to S3 meaning better testing.
> 
> Whether its slower depends on the hardware; on my 128MB Celeron 933
> laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
> back up and running in around a minute and a half. That's about the same
> as far as I remember, but has (as you say) the advantage of not still
> having to get things swapped back in.
> 
> > If you already have hibernation partition from factory, which you are
> > using anyway for w98, S4bios is easier to use and more foolproof
> > (i.e. you can't boot into wrong kernel which does not resume but does
> > fsck instead).
> 
> It doesn't really matter what kernel is loaded when we start a resume
> anyway, does it? Could they not be different versions because one is
> going to replace the other anyway?

No, no. It has to be exactly the same kernel, otherwise you get a nice
crash (if you are lucky) and ugly data corruption (when you are not);
there's check to prevent that and panic, however.

That's why I call S4bios more foolproof.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Lyle Seaman]

> 
> No, no. It has to be exactly the same kernel, otherwise you get a nice
> crash (if you are lucky) and ugly data corruption (when you are not);
> there's check to prevent that and panic, however.

but why does this happen?  is the kernel text not being replaced?




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham]

On Thu, 2003-02-06 at 23:16, Ducrot Bruno wrote:
> On Thu, Feb 06, 2003 at 09:41:44AM +1300, Nigel Cunningham wrote:
> > Whether its slower depends on the hardware; on my 128MB Celeron 933
> > laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
> > back up and running in around a minute and a half. That's about the same
> > as far as I remember, but has (as you say) the advantage of not still
> > having to get things swapped back in.
> 
> The problem is the speed of the suspending process, not the whole suspend/resume
> sequence,  especially in case of emergency suspending due to thermal condition,
> etc.

Sorry. Perhaps I should have been clearer. I haven't spent a lot of time
doing timings, but there doesn't seem to be any significant difference.
In both versions, the amount of time varies with the amount of memory in
use. When not much memory is in use, both are fast because there's not
much to do anyway. When lots of memory is in use, both are slower. The
old version is slower because it eats as much memory as it can, and this
can take significant amounts of time, then makes a copy of every page
remaining, before saving those pages to disk. The new version doesn't
usually eat any memory, and when it does, not much is eaten. It then
saves all the pages that aren't needed for the suspend process directly
to disk; always more than half, sometimes all but about a few thousand
pages. It then uses this memory for the copy & save of remaining pages.
Thus, in one version, the major portion of time is taken in eating
memory (and post resume, loading pages back in) whereas in the 'new'
version, the time taken is almost purely a function of IO speed.

If you like, I'll do some timings on my 320MB desktop machine and post
them later in the day.

Regards,

Nigel

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham]

On Fri, 2003-02-07 at 04:37, Pavel Machek wrote:

> No, no. It has to be exactly the same kernel, otherwise you get a nice
> crash (if you are lucky) and ugly data corruption (when you are not);
> there's check to prevent that and panic, however.
> 
> That's why I call S4bios more foolproof.

Oh of course; I'm with you. If you're running a different kernel, you
must have had an entirely different context when you suspended. Humble
apologies; I was only thinking about whether the image would
successfully load, not the difference in contents.

Regards,

Nigel

Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Ducrot Bruno]

On Wed, Feb 05, 2003 at 01:40:41AM +0000, Matthew Garrett wrote:
> On Fri, Jan 31, 2003 at 06:39:04PM +0100, Ducrot Bruno wrote:
> 
> Hi Ducrot,
> 
> > This is the 'minimal' requirement.  Some devices (especially the
> > IDE part) are not well resumed.  Handle with care..
> 
> Using this patch (on top of 2.5.59 and acpi 20030123), echo 4b 
> >/proc/acpi/sleep results in the system freezing all of the processes 
> and then resetting itself without any state change. This is an IBM 
> Thinkpad 240x which claims to support S4Bios, and I have the appropriate 
> partition. Would it be worth me enabling debugging and hooking up a 
> serial console?
> 

Strange.  What say dmesg?

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Ducrot Bruno]

On Fri, Feb 07, 2003 at 08:41:27AM +1300, Nigel Cunningham wrote:
> On Thu, 2003-02-06 at 23:16, Ducrot Bruno wrote:
> > On Thu, Feb 06, 2003 at 09:41:44AM +1300, Nigel Cunningham wrote:
> > > Whether its slower depends on the hardware; on my 128MB Celeron 933
> > > laptop (17MB/s HDD), I can write an image of about 120MB, reboot and get
> > > back up and running in around a minute and a half. That's about the same
> > > as far as I remember, but has (as you say) the advantage of not still
> > > having to get things swapped back in.
> > 
> > The problem is the speed of the suspending process, not the whole suspend/resume
> > sequence,  especially in case of emergency suspending due to thermal condition,
> > etc.
> 
> Sorry. Perhaps I should have been clearer. I haven't spent a lot of time
> doing timings, but there doesn't seem to be any significant difference.
> In both versions, the amount of time varies with the amount of memory in

Ah ok.  I understand now.  S4bios is completely different from swsusp.
It's just as if we were comparing APM suspend-to-disk and swsusp (and no, S4bios
is *not* APM suspend-to-disk either).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Matthew Garrett]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

On Thu, Feb 06, 2003 at 09:56:08PM +0100, Ducrot Bruno wrote:
> On Wed, Feb 05, 2003 at 01:40:41AM +0000, Matthew Garrett wrote:
> > Using this patch (on top of 2.5.59 and acpi 20030123), echo 4b 
> > >/proc/acpi/sleep results in the system freezing all of the processes 
> > and then resetting itself without any state change. This is an IBM 
> > Thinkpad 240x which claims to support S4Bios, and I have the appropriate 
> > partition. Would it be worth me enabling debugging and hooking up a 
> > serial console?
> > 
> 
> Strange.  What say dmesg?

Included dmesg is what I have after boot. FWIW, suspend to disk "works" 
under APM (system suspends, restores, dies due to failing to deal with 
IDE interrupts). There is a newer BIOS available that claims to fix some 
issues with ACPI on Windows XP, which I can try if you think it'd be 
worth it. I've no kernel output of a suspend attempt because the machine 
reboots itself immediately, but I can hook up a serial console if you'd 
like.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 9584 bytes --]

Linux version 2.5.59 (root@asparagine) (gcc version 3.2.2 20030129 (Debian prerelease)) #2 Wed Feb 5 01:52:04 GMT 2003
Video mode to be used for restore is f00
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000bff0000 (usable)
 BIOS-e820: 000000000bff0000 - 000000000bfffc00 (ACPI data)
 BIOS-e820: 000000000bfffc00 - 000000000c000000 (ACPI NVS)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
191MB LOWMEM available.
ACPI: have wakeup address 0xc0001000
On node 0 totalpages: 49136
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 45040 pages, LIFO batch:10
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 PTLTD                      ) @ 0x000f6c80
ACPI: RSDT (v001 PTLTD    RSDT   01540.00000) @ 0x0bffc972
ACPI: FADT (v001 IBM    TP240    01540.00000) @ 0x0bfffb65
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 01540.00000) @ 0x0bfffbd9
ACPI: DSDT (v001    PTL    BX-TJ 01540.00000) @ 0x00000000
ACPI: BIOS passes blacklist
IBM machine detected. Enabling interrupts during APM calls.
IBM machine detected. Disabling SMBus accesses.
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=Linux ro root=306 video=vesa resume=/dev/hda5 reboot=w
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 497.735 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 985.08 BogoMIPS
Memory: 190788k/196544k available (2134k kernel code, 5120k reserved, 659k data, 128k init, 0k highmem)
Security Scaffold v1.0.0 initialized
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU:     After generic, caps: 0383f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 06
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
EISA bus registered
EISA: Probing bus...
EISA: Detected 0 card.
PCI: PCI BIOS revision 2.10 entry at 0xfd9df, last bus=0
PCI: Using configuration type 1
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 256 entries (12 bytes)
biovec pool[1]:   4 bvecs: 256 entries (48 bytes)
biovec pool[2]:  16 bvecs: 256 entries (192 bytes)
biovec pool[3]:  64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20030122
    ACPI-0262: *** Info: GPE Block0 defined as GPE0 to GPE15
    ACPI-0262: *** Info: GPE Block1 defined as GPE16 to GPE31
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: (supports S0 S1 S3 S4 S4bios S5)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 11 14 15, disabled)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 14 15)
ACPI: Embedded Controller [EC0] (gpe 25)
ACPI: Power Resource [PCR0] (off)
ACPI: Power Resource [PFAN] (off)
Linux Plug and Play Support v0.94 (c) Adam Belay
pnp: Enabling Plug and Play Card Services.
PnPBIOS: Found PnP BIOS installation structure at 0xc00f6d20
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xac81, dseg 0x400
PnPBIOS: 19 nodes reported by PnP BIOS; 19 recorded by driver
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
block request queues:
 128 requests per read queue
 128 requests per write queue
 8 requests per batch
 enter congestion at 15
 exit congestion at 17
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
ACPI: No IRQ known for interrupt pin A of device 00:09.0 - using IRQ 255
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
SBF: ACPI BOOT descriptor is wrong length (39)
SBF: Simple Boot Flag extension found and enabled.
SBF: Setting boot flags 0x1
IA-32 Microcode Update Driver: v1.11 <tigran-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Enabling SEP on CPU 0
aio_setup: sizeof(struct page) = 40
Journalled Block Device driver loaded
devfs: v1.22 (20021013) Richard Gooch (rgooch-r1x6VkxMR+00zabcByZE4g@public.gmane.org)
devfs: boot_options: 0x0
Capability LSM initialized
Initializing Cryptographic API
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SBTN]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: Processor [CPU0] (supports C1 C2 C3, 8 throttling states)
ACPI: Thermal Zone [THRM] (31 C)
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled
tts/0 at I/O 0x3f8 (irq = 4) is a 16550A
tts/1 at I/O 0x2f8 (irq = 3) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 00:07.1
PIIX4: chipset revision 0
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:pio, hdd:pio
hda: IBM-DARA-212000, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: host protected area => 1
hda: 23579136 sectors (12073 MB) w/418KiB Cache, CHS=23392/16/63, UDMA(33)
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 >
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus] [pm]
mice: PS/2 mouse device common for all mice
input: PC Speaker
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Advanced Linux Sound Architecture Driver Version 0.9.0rc6 (Tue Dec 17 19:01:13 2002 UTC).
request_module[snd-card-0]: not ready
request_module[snd-card-1]: not ready
request_module[snd-card-2]: not ready
request_module[snd-card-3]: not ready
request_module[snd-card-4]: not ready
request_module[snd-card-5]: not ready
request_module[snd-card-6]: not ready
request_module[snd-card-7]: not ready
ALSA device list:
  No soundcards found.
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
BIOS EDD facility v0.07 2002-Oct-24, 1 devices found
Yenta IRQ list 0098, PCI irq11
Socket status: 30000010
Resume Machine: resuming from /dev/hda5
Resuming from device ide0(3,5)
Resume Machine: This is normal swap space
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: ide0(3,6): orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 179955
EXT3-fs: ide0(3,6): 1 orphan inode deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 128k freed
Adding 409616k swap on /dev/hda5.  Priority:-1 extents:1
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,6), internal journal
Real Time Clock Driver v1.11
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?
cs4281: version v1.13.32 time 01:56:51 Feb  5 2003
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
uhci-hcd 00:07.2: Intel Corp. 82440MX USB Universa
uhci-hcd 00:07.2: irq 11, io base 00001400
Please use the 'usbfs' filetype instead, the 'usbdevfs' name is deprecated.
uhci-hcd 00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:0: USB hub found
hub 1-0:0: 2 ports detected
ttyS2: LSR safety check engaged!
ttyS2: LSR safety check engaged!
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x398-0x39f 0x3b8-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
hermes.c: 4 Jul 2002 David Gibson <hermes-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
orinoco.c 0.13a (David Gibson <hermes-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> and others)
orinoco_cs.c 0.13a (David Gibson <hermes-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> and others)
eth0: Station identity 001f:0004:0001:0003
eth0: Looks like an Intersil firmware version 1.3.4
eth0: Ad-hoc demo mode supported
eth0: IEEE standard IBSS ad-hoc mode supported
eth0: WEP supported, 104-bit key
eth0: MAC address 00:60:B3:68:A4:47
eth0: Station name "Prism  I"
eth0: ready
eth0: index 0x01: Vcc 5.0, irq 3, io 0x0100-0x013f
eth0: New link status: Connected (0001)
Module cs4281 cannot be unloaded due to unsafe usage in include/linux/module.h:430

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham]

On Fri, 2003-02-07 at 10:05, Ducrot Bruno wrote:
> On Fri, Feb 07, 2003 at 08:41:27AM +1300, Nigel Cunningham wrote:
> > Sorry. Perhaps I should have been clearer. I haven't spent a lot of time
> > doing timings, but there doesn't seem to be any significant difference.
> > In both versions, the amount of time varies with the amount of memory in
> 
> Ah ok.  I understand now.  S4bios is completely different from swsusp.
> It's just as if we were comparing APM suspend-to-disk and swsusp (and no, S4bios
> is *not* APM suspend-to-disk either).

FWIW, here are the results of some tests, timing
2.4.21-pre3+acpi20030125+swsusp-beta18:

Machine 1: Celeron 933 laptop 17MB/s disk throughput, 128MB RAM
Machine 2: Duron 700 desktop, 30MB/s disk throughput, 320MB RAM

Algorithm 1: Eat as much memory as possible, save remaining in one set
of pages
Algorithm 2: Save memory in two pages, only eating memory if necessary.

Same code base, just different parameters to /proc/sys/kernel/swsusp.
This means that the result for algorithm 1 are exactly the same as
Pavel's code, but should give some idea.

Columns:
(1) Machine
(2) Algorithm
(3) Initial # pages free
(4) Image size written to disk
(5) Approximate time taken (date command run on other computer at same
time as pressing enter to start command, then when computer restarts)

1  2  3           4     5
---------------------------------
1  1  25655/30592  1562 0:07
1  2  26246/30592  4302 0:05
1  1   1005/30592  5165 0:20
1  2    900/30592 30126 0:16
2  1  38604/79755     ? 0:49
2  2  39122/79755 30398 0:21
2  1   1113/79755     ? 0:50
2  2   1109/79755 82149 0:40

The question marks are because the desktop machine didn't successfully
resume using this algorithm, so stats weren't logged (probably driver
problems).

In each case, the new method is slightly faster than the old, so we don't seem to loose anything.
Particularly interesting to me was the fact that the gain was not as
high as we might expect when the memory was heavily used. I guess the
amount of I/O is getting to the point where benefits from not eating
pages are being erroded. It would be interesting to see if a machine
with more memory readed a point where it was faster to eat the memory
instead of write it.

Hope this is helpful.

Nigel

Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Pavel Machek]

Hi!

> Hi Ducrot,
> 
> > This is the 'minimal' requirement.  Some devices (especially the
> > IDE part) are not well resumed.  Handle with care..

Good news: works for me. Either I have to disable vesafb *or* pass
acpi_sleep=s3_mode, but it works (2.5.59 on hp omnibook xe3).

There are some glitches, through. Sometimes it takes > 10 seconds
before the BIOS's progress bars shown (and I have powered down at
this point thinking machine is dead). And once it did save to disk but
did not power down after that.

> Using this patch (on top of 2.5.59 and acpi 20030123), echo 4b 
> >/proc/acpi/sleep results in the system freezing all of the processes 
> and then resetting itself without any state change. This is an IBM 
> Thinkpad 240x which claims to support S4Bios, and I have the appropriate 
> partition. Would it be worth me enabling debugging and hooking up a 
> serial console?

Yes, plus you might want to add some printks to see where exactly it
dies.

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Pavel Machek]

Hi!

> Machine 1: Celeron 933 laptop 17MB/s disk throughput, 128MB RAM
> Machine 2: Duron 700 desktop, 30MB/s disk throughput, 320MB RAM
> 
> Algorithm 1: Eat as much memory as possible, save remaining in one set
> of pages
> Algorithm 2: Save memory in two pages, only eating memory if necessary.
> 
> Same code base, just different parameters to /proc/sys/kernel/swsusp.
> This means that the result for algorithm 1 are exactly the same as
> Pavel's code, but should give some idea.
> 
> Columns:
> (1) Machine
> (2) Algorithm
> (3) Initial # pages free
> (4) Image size written to disk
> (5) Approximate time taken (date command run on other computer at same
> time as pressing enter to start command, then when computer restarts)
> 
> 1  2  3           4     5
> ---------------------------------
> 1  1  25655/30592  1562 0:07
> 1  2  26246/30592  4302 0:05

You can suspend and resume your notebook within 5 seconds? Wow!

> 1  1   1005/30592  5165 0:20
> 1  2    900/30592 30126 0:16
> 2  1  38604/79755     ? 0:49
> 2  2  39122/79755 30398 0:21
> 2  1   1113/79755     ? 0:50
> 2  2   1109/79755 82149 0:40
> 
> The question marks are because the desktop machine didn't successfully
> resume using this algorithm, so stats weren't logged (probably driver
> problems).
> 
> In each case, the new method is slightly faster than the old, so we don't seem to loose anything.
> Particularly interesting to me was the fact that the gain was not as
> high as we might expect when the memory was heavily used. I guess the
> amount of I/O is getting to the point where benefits from not eating
> pages are being erroded. It would be interesting to see if a machine
> with more memory readed a point where it was faster to eat the memory
> instead of write it.

Well, if all the memory is in disk-backed clean pages, it should be
faster to discard then write out...

Anyway... So your method is faster. Good. Now, how much more
complicated is it?
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?

Re: Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Pavel Machek]

Hi!

> > No, no. It has to be exactly the same kernel, otherwise you get a nice
> > crash (if you are lucky) and ugly data corruption (when you are not);
> > there's check to prevent that and panic, however.
> 
> but why does this happen?  is the kernel text not being replaced?

Kernel text is not replaced, and we rely on kernel being same size as
before.

								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: [ACPI] Re: [PATCH] s4bios for 2.5.59 + apci-20030123

[Nigel Cunningham]

Hi

On Sat, 2003-02-08 at 05:00, Pavel Machek wrote: 
> > 1  2  3           4     5
> > --
> > 1  1  25655/30592  1562 0:07
> > 1  2  26246/30592  4302 0:05
> 
> You can suspend and resume your notebook within 5 seconds? Wow!

As requested, these were just the times for suspending.

> Well, if all the memory is in disk-backed clean pages, it should be
> faster to discard then write out...

Yes, I would think so too. Perhaps the differences would probably
disappear if I made the algorithm more like your original (ie simplifed
eat_memory back to the original), but I do remember lots of disk
activity when using the original code as well - perhaps the cause might
be worth further investigation? (Not that I'm volunteering)

> Anyway... So your method is faster. Good. Now, how much more
> complicated is it?

As I've said above, I'm not sure it is right to say it is faster - I
didn't compare your current method with the new one, but rather mine
with parameters making the algorithm as close to yours as possible. My
point was more that if the new method is slower, its not significantly
slower.

Nevertheless, you do have a good point - it is more complicated. But I
think it's worth it and its not a lot more complicated. People who are
using the new method at the moment appreciate the changes. Don't think
for a moment that I don't value your work, Pavel. I couldn't have done
any of my additions without it and consider mine tweaking. This has
simply been a quest to get a more responsive system on resume.

Regards,

Nigel