Re: [2.5.50, ACPI] link error

Re: [2.5.50, ACPI] link error

[Patrick Mochel]

> > S3 support is a subset of what is need for S4 support. 
> 
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.

Ok, acpi_wakeup.S is only for S3.

As for drivers, I'm dubious of swsusp's handling of device and driver
support. A suspend cycle is supposed to leave devices in the same state
they were in before the cycle.  So, you need suspend and resume hooks in
the drivers, even for S4 support, to capture and restore context in the
devices themselves. Then again, I've no proof that swsusp doesn't get 
everything right as is.

> > CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
> > support. 
> 
> What's ACPI side of S4 good for when you can not do S4?

To not litter the code with #ifdefs. 

> > The comment in the config option should tell the user that they 
> > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> > ACPI side can make an empty call to swsusp if no implementation is 
> > selected). 
> 
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...

Then break it up into separate files in a separate directory.

> > Some time ago, I made a BK repo for suspend support. I axed it, since no 
> > one ever used it. But, it's back again, and I'll be integrating your 
> > patches and try to dedicate a few extra cycles to resolving some of the 
> > issues. I'll send an announcement to the list once I've integrated your 
> > patches. 
> 
> I probably will not persuade you to make it CVS, right? [Sorry, I'm
> not going to touch bitkeeper.]

I know, and that's fine. I won't touch CVS again, unless there's a hefty 
sum and a lot of good beer involved. (Or, after I've consumed a lot of 
good beer). Patches can be made from the repo, most easily after merging 
to a new kernel version.

	-pat

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > Doesn't that imply your fix is broken to begin with?
> > 
> > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > overdesign to me, OTOH if you do the work it is okay with me.
> 
> You broke the design. S3 support was developed long before swsusp was in 
> the kernel, and completely indpendent of it. It should have remained that 
> way. 
> 
> S3 support is a subset of what is need for S4 support. 

That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
but not for S4. Big part of driver support is only needed for S3.

> swsusp is an implementation of S4 support. In theory, there could be 
> multiple implementations that all use the same core (saving/restoring 
> state). 

There were patches for S4bios floating around, but it never really
worked, IIRC.

> There could also be different power management schemes that use swsusp as 
> an implementation for suspend-to-disk. But, that's another tangent. 
> 
> CONFIG_ACPI_SLEEP should give you S3 support, and the ACPI side of S4 
> support. 

What's ACPI side of S4 good for when you can not do S4?

> The comment in the config option should tell the user that they 
> must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> ACPI side can make an empty call to swsusp if no implementation is 
> selected). 

S3 needs process stopper from kernel/suspend.c. I did not want to have
#ifdefs all over suspend.c...

> Some time ago, I made a BK repo for suspend support. I axed it, since no 
> one ever used it. But, it's back again, and I'll be integrating your 
> patches and try to dedicate a few extra cycles to resolving some of the 
> issues. I'll send an announcement to the list once I've integrated your 
> patches. 

I probably will not persuade you to make it CVS, right? [Sorry, I'm
not going to touch bitkeeper.]
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> 
> Ok, acpi_wakeup.S is only for S3.
> 
> As for drivers, I'm dubious of swsusp's handling of device and driver
> support. A suspend cycle is supposed to leave devices in the same state

Some devices do not really have a state (timer -- it needs to be set
to 1kHz, but that's it), and they do not need support for S4 but need
it for S3.

> > > The comment in the config option should tell the user that they 
> > > must choose a suspend implementation (e.g. CONFIG_SUSPEND, which should 
> > > prolly be CONFIG_SWAP_SUSPEND) in order to get complete S4 support. (The 
> > > ACPI side can make an empty call to swsusp if no implementation is 
> > > selected). 
> > 
> > S3 needs process stopper from kernel/suspend.c. I did not want to have
> > #ifdefs all over suspend.c...
> 
> Then break it up into separate files in a separate directory.

Uff, having kernel/suspend/freezer.c and kernel/suspend/disk.c would
seem very ugly to me, and freezer is pretty short in fact... I do not
think we want separate directory for suspend.

> > > Some time ago, I made a BK repo for suspend support. I axed it, since no 
> > > one ever used it. But, it's back again, and I'll be integrating your 
> > > patches and try to dedicate a few extra cycles to resolving some of the 
> > > issues. I'll send an announcement to the list once I've integrated your 
> > > patches. 
> > 
> > I probably will not persuade you to make it CVS, right? [Sorry, I'm
> > not going to touch bitkeeper.]
> 
> I know, and that's fine. I won't touch CVS again, unless there's a hefty 
> sum and a lot of good beer involved. (Or, after I've consumed a lot of 
> good beer). Patches can be made from the repo, most easily after merging 
> to a new kernel version.

:-) there should be some good beer around here ;-).

I'd like to keep it simple for now. I feel alone developing sleep on
2.5, and it is easier for me not to ave to test different
configurations. So I think ACPI_SLEEP requiring SOFTWARE_SUSPEND is
okay for now (code bloat is not too bad). If you are joining and will
work on ACPI_SLEEP && !SOFTWARE_SUSPEND, you can easily catch
non-compilations and similar mistakes, and it will be okay to separate
the two.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [2.5.50, ACPI] link error

[Jeff Garzik]

Pavel Machek wrote:
> S3 needs process stopper from kernel/suspend.c. I did not want to have
> #ifdefs all over suspend.c...


Then move it to a different file, that may be shared between various 
CONFIG_xxx features.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > Doesn't that imply your fix is broken to begin with?
> > > 
> > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > overdesign to me, OTOH if you do the work it is okay with me.
> > 
> > You broke the design. S3 support was developed long before swsusp was in 
> > the kernel, and completely indpendent of it. It should have remained that 
> > way. 
> > 
> > S3 support is a subset of what is need for S4 support. 
> 
> That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> but not for S4. Big part of driver support is only needed for S3.
> 
> > swsusp is an implementation of S4 support. In theory, there could be 
> > multiple implementations that all use the same core (saving/restoring 
> > state). 
> 
> There were patches for S4bios floating around, but it never really
> worked, IIRC.

No.  It work.  I do not resubmmited patches because I think that
swsusp is better.

-- 
Ducrot Bruno

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

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

Hi, Pavel.

On Fri, Dec 06, 2002 at 07:57:02PM +0100, Ducrot Bruno wrote:
> On Fri, Dec 06, 2002 at 01:06:18AM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.
> 

I attach also this patch, it is ughly, though, but if you are sure
that your laptop can support S4BIOS (I do not include basic checks for
that), it should survive (I need myself to reset at wakeup the keyboard controller,
though).

It is again acpi on sf.net of today, and some of your patches for S3 support.

echo 4b > /proc/acpi/sleep if you want to say goodbye to your data :)

Cheers,

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

[-- Attachment #2: s4bios-2.5.50.diff --]
[-- Type: text/plain, Size: 5017 bytes --]

--- linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:34:17	1.1
+++ linux-2.5.50/arch/i386/kernel/acpi_wakeup.S	2002/12/06 21:48:14
@@ -336,6 +336,48 @@
 	pushl saved_context_eflags ; popfl
 	ret
 
+ENTRY(do_suspend_lowlevel_s4bios)
+	cmpl $0,4(%esp)
+	jne .L1432
+	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 $.L1432,saved_eip
+	movl %esp,saved_esp
+	movl %ebp,saved_ebp
+	movl %ebx,saved_ebx
+	movl %edi,saved_edi
+	movl %esi,saved_esi
+
+	pushl $3
+	call acpi_enter_sleep_state_s4bios
+	addl $4,%esp
+	ret
+	.p2align 4,,7
+.L1433:
+	movl $__KERNEL_DS,%eax
+	movw %ax, %ds
+	movl saved_context_esp, %esp
+	movl saved_context_ebp, %ebp
+	movl saved_context_eax, %eax
+	movl saved_context_ebx, %ebx
+	movl saved_context_ecx, %ecx
+	movl saved_context_edx, %edx
+	movl saved_context_esi, %esi
+	movl saved_context_edi, %edi
+	call restore_processor_state
+	pushl saved_context_eflags ; popfl
+	ret
+
 ALIGN
 # saved registers
 saved_gdt:	.long	0,0
--- linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 21:56:49	1.1
+++ linux-2.5.50/drivers/acpi/include/acpixf.h	2002/12/06 22:02:42
@@ -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.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 21:39:07	1.1
+++ linux-2.5.50/drivers/acpi/hardware/hwsleep.c	2002/12/06 22:08:22
@@ -319,6 +319,51 @@
 
 /******************************************************************************
  *
+ * 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();
+
+	acpi_os_stall (10000);
+
+	status = acpi_os_write_port (acpi_gbl_FADT->smi_cmd, (acpi_integer) acpi_gbl_FADT->S4bios_req, 8);
+
+	do {
+		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
  *
  * PARAMETERS:  Sleep_state         - Which sleep state we just exited
--- linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 21:21:25	1.1
+++ linux-2.5.50/drivers/acpi/sleep.c	2002/12/06 22:29:28
@@ -149,8 +149,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);
@@ -227,6 +229,8 @@
 	case ACPI_STATE_S3:
 		do_suspend_lowlevel(0);
 #endif
+	case ACPI_STATE_S4:
+		do_suspend_lowlevel_s4bios(0);
 		break;
 	}
 	local_irq_restore(flags);
@@ -253,7 +257,7 @@
 	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) {
+	if (state == ACPI_STATE_S2 || state == ACPI_STATE_S3 || state == ACPI_STATE_S4) {
 		if (!acpi_wakeup_address)
 			return AE_ERROR;
 		acpi_set_firmware_waking_vector((ACPI_PHYSICAL_ADDRESS) acpi_wakeup_address);
@@ -336,12 +340,14 @@
 	if (!sleep_states[state])
 		return_VALUE(-ENODEV);
 
+	if (state == 4 && state_string[1] != 'b') {
 #ifdef CONFIG_SOFTWARE_SUSPEND
-	if (state == 4) {
+	/* if (state == 4) { */
 		software_suspend();
 		return_VALUE(count);
-	}
+	/* } */
 #endif
+	}
 	status = acpi_suspend(state);
 
 	if (ACPI_FAILURE(status))
--- linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:58:48	1.1
+++ linux-2.5.50/drivers/acpi/acpi_ksyms.c	2002/12/06 21:59:12
@@ -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.50/include/linux/suspend.h	2002/12/06 21:53:17	1.1
+++ linux-2.5.50/include/linux/suspend.h	2002/12/06 21:54:27
@@ -71,6 +71,8 @@
 
 extern void do_suspend_lowlevel(int resume);
 
+extern void do_suspend_lowlevel_s4bios(int resume);
+
 #else
 static inline void software_suspend(void)
 {

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > > > > Doesn't that imply your fix is broken to begin with?
> > > > 
> > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > 
> > > You broke the design. S3 support was developed long before swsusp was in 
> > > the kernel, and completely indpendent of it. It should have remained that 
> > > way. 
> > > 
> > > S3 support is a subset of what is need for S4 support. 
> > 
> > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > but not for S4. Big part of driver support is only needed for S3.
> > 
> > > swsusp is an implementation of S4 support. In theory, there could be 
> > > multiple implementations that all use the same core (saving/restoring 
> > > state). 
> > 
> > There were patches for S4bios floating around, but it never really
> > worked, IIRC.
> 
> No.  It work.  I do not resubmmited patches because I think that
> swsusp is better.

I think that s4bios is nice to have. Its similar to S3 and easier to
set up than swsusp... It would be nice to have it.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Constantinos Antoniou]

On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

(I do not know much, but) another reason may be that some laptops do not
support S3, while they support S4? for example, in my Compaq Presario
1700T:

$ more /proc/acpi/info
ACPI-CA Version:         20011018
Sx States Supported:     S0 S1 S4 S5

(unpatched 2.4.19, if this has anything to do)

Costas

> 								Pavel
-- 
Constantinos Antoniou
Ph.D. Candidate
Massachusetts Institute of Technology
Intelligent Transportation Systems Program
77 Massachusetts Ave., NE20-208, Cambridge, MA 02139
(T) 617-252-1113 * (F) 617-252-1130 * (email) costas-3s7WtUTddSA@public.gmane.org

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

Hi Pavel:

On Sun, Dec 08, 2002 at 08:49:45PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > 
> > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > 
> > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > way. 
> > > > 
> > > > S3 support is a subset of what is need for S4 support. 
> > > 
> > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > but not for S4. Big part of driver support is only needed for S3.
> > > 
> > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > multiple implementations that all use the same core (saving/restoring 
> > > > state). 
> > > 
> > > There were patches for S4bios floating around, but it never really
> > > worked, IIRC.
> > 
> > No.  It work.  I do not resubmmited patches because I think that
> > swsusp is better.
> 
> I think that s4bios is nice to have. Its similar to S3 and easier to
> set up than swsusp... It would be nice to have it.

for me:
pros:
-----
1- it is really really more easier to implement than S4;
2- we can even have it with 2.4 kernels (it seems that it work without
the need of freezing processes, but I suspect that this statement
is 'wrong' by nature).

cons:
-----
1- it is much slower (especially at save time) than your swsusp;
2- end users must setup their systems (need to create a suspend partition,
or to keep a vfat partition as the really first one (/dev/hda1));
3- we use a bios function.  Actually, everything can happen...

That why I prefer swsusp at this time, or any other implementation of S4 (I
think about an implementation of S4 via LKCD).

Cheers,

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Sun, Dec 08, 2002 at 03:46:20PM -0500, Constantinos Antoniou wrote:
> On Sun, 2002-12-08 at 14:49, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > > Doesn't that imply your fix is broken to begin with?
> > > > > > 
> > > > > > ACPI/S4 support needs swsusp. ACPI/S3 needs big part of
> > > > > > swsusp. Splitting CONFIG_ACPI_SLEEP to S3 and S4 part seems like
> > > > > > overdesign to me, OTOH if you do the work it is okay with me.
> > > > > 
> > > > > You broke the design. S3 support was developed long before swsusp was in 
> > > > > the kernel, and completely indpendent of it. It should have remained that 
> > > > > way. 
> > > > > 
> > > > > S3 support is a subset of what is need for S4 support. 
> > > > 
> > > > That's not true. acpi_wakeup.S is nasty piece of code, needed for S3
> > > > but not for S4. Big part of driver support is only needed for S3.
> > > > 
> > > > > swsusp is an implementation of S4 support. In theory, there could be 
> > > > > multiple implementations that all use the same core (saving/restoring 
> > > > > state). 
> > > > 
> > > > There were patches for S4bios floating around, but it never really
> > > > worked, IIRC.
> > > 
> > > No.  It work.  I do not resubmmited patches because I think that
> > > swsusp is better.
> > 
> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> (I do not know much, but) another reason may be that some laptops do not
> support S3, while they support S4? for example, in my Compaq Presario
> 1700T:
> 
> $ more /proc/acpi/info
> ACPI-CA Version:         20011018
> Sx States Supported:     S0 S1 S4 S5

Some southbrigdes have well know design flaw that prevent a 'good' S3
functionality.  Those this is disabled.

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

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] 

> > I think that s4bios is nice to have. Its similar to S3 and easier to
> > set up than swsusp... It would be nice to have it.
> 
> for me:
> pros:
> -----
> 1- it is really really more easier to implement than S4;
> 2- we can even have it with 2.4 kernels (it seems that it work without
> the need of freezing processes, but I suspect that this statement
> is 'wrong' by nature).
> 
> cons:
> -----
> 1- it is much slower (especially at save time) than your swsusp;
> 2- end users must setup their systems (need to create a 
> suspend partition,
> or to keep a vfat partition as the really first one (/dev/hda1));
> 3- we use a bios function.  Actually, everything can happen...
> 
> That why I prefer swsusp at this time, or any other 
> implementation of S4 (I
> think about an implementation of S4 via LKCD).

I concur with your pros and cons. This makes me think that if S4BIOS support
ever gets added, it should get added to 2.4 only.

Regards -- Andy

RE: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Mon, 2002-12-09 at 19:12, Grover, Andrew wrote:
> I concur with your pros and cons. This makes me think that if S4BIOS support
> ever gets added, it should get added to 2.4 only.

That assumes no box exists where S4bios works an S4 doesnt (eg due to
bad tables or "knowing" what other-os does)

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Pavel Machek]

Hi!

> > I concur with your pros and cons. This makes me think that if S4BIOS support
> > ever gets added, it should get added to 2.4 only.

And S4BIOS will never get added to 2.4 since it needs driver model
:-(.

> That assumes no box exists where S4bios works an S4 doesnt (eg due to
> bad tables or "knowing" what other-os does)

We have full control over S4 (== swsusp), so we can fix that in most
cases.

S4BIOS is still little friendlier to the user -- no need to set up
swap partition and command line parameter, can't go wrong if you boot
without resume=, etc.
								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Andrew McGregor]

I strongly suspect that s4bios will work on this machine, but swsusp won't. 
Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
put pm support in their driver, it's game over for Linux.  Except that the 
BIOS knows how to suspend it, so some kernel/driver combinations work with 
APM.  I suspect any Geforce2go Dell is the same.

Andrew

--On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org> 
wrote:

> Hi!
>
>> > I concur with your pros and cons. This makes me think that if S4BIOS
>> > support ever gets added, it should get added to 2.4 only.
>
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.
>
>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>> bad tables or "knowing" what other-os does)
>
> We have full control over S4 (== swsusp), so we can fix that in most
> cases.
>
> S4BIOS is still little friendlier to the user -- no need to set up
> swap partition and command line parameter, can't go wrong if you boot
> without resume=, etc.
> 								Pavel
>
> --
> Casualities in World Trade Center: ~3k dead inside the building,
> cryptography in U.S.A. and free speech in Czech Republic.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Tue, Dec 10, 2002 at 09:40:31PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > I concur with your pros and cons. This makes me think that if S4BIOS support
> > > ever gets added, it should get added to 2.4 only.
> 
> And S4BIOS will never get added to 2.4 since it needs driver model
> :-(.

Well, it worked for me with 2.4 with 'basic' pm_send_xxx

-- 
Ducrot Bruno

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Ducrot Bruno]

On Wed, Dec 11, 2002 at 09:50:48AM +1300, Andrew McGregor wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp won't. 
> Why?  It's a Dell Inspiron 8000 with an NVidia Geforce2go, and until NVidia 
> put pm support in their driver, it's game over for Linux.  Except that the 
> BIOS knows how to suspend it, so some kernel/driver combinations work with 
> APM.  I suspect any Geforce2go Dell is the same.

No.  You are wrong.  I need to suspend allmost all the drivers, and the
video chipset is not an execption (or go to a console before suspending,
in fact).
You still need to bug NVIDIA in order to have proper pm support
in their driver.

-- 
Ducrot Bruno

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

Re: [ACPI] Re: [2.5.50, ACPI] link error

[Alan Cox]

On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> No.  You are wrong.  I need to suspend allmost all the drivers, and the
> video chipset is not an execption (or go to a console before suspending,
> in fact).
> You still need to bug NVIDIA in order to have proper pm support
> in their driver.

To an extent. However you can also switch back to text mode on suspend
to disk, then resume back into text mode and effectively switch back
into X11