ACPI poweroff fixes for 2.4.26-pre2]

you can try this one

-----Forwarded Message-----

Quoted 87 lines

From: Willy Tarreau <[email protected]>
To: Pavel Machek <[email protected]>
Cc: Marcelo Tosatti <marcelo.tosatti-3EexvZdKGZRWk0Htik3J/[email protected]>, [email protected], [email protected]
Subject: [ACPI] [PATCH] ACPI poweroff fixes for 2.4.26-pre2
Date: Wed, 10 Mar 2004 00:33:25 +0100

Hi Pavel,

Quoted 10 lines · Pavel Machek

Can you replace

acpi_system_save_state() with

        pm_send_all(PM_SAVE_STATE, (void *)3);
        pm_send_all(PM_SUSPEND, (void *)3);

?

That should fix it, too, and does not depend on CONFIG_ACPI_SLEEP.

Just checked, and I still can poweroff (which was a bit expected anyway, but now confirmed). So with this little patch against 2.4.26-pre2, poweroff does not depend on CONFIG_ACPI_SLEEP anymore, as you fairly requested (thank you for having insisted).

diff -urN linux-2.4.26-pre2/drivers/acpi/system.c linux-2.4.26-pre2-pwoff/drivers/acpi/system.c

drivers/acpi/system.c +2 -8

@@ -45,13 +45,6 @@
 #include <linux/mc146818rtc.h>
 #include <linux/irq.h>
 #include <asm/hw_irq.h>
-
-acpi_status acpi_system_save_state(u32);
-#else
-static inline acpi_status acpi_system_save_state(u32 state)
-{
-	return AE_OK;
-}
 #endif /* !CONFIG_ACPI_SLEEP */
 
 #define _COMPONENT		ACPI_SYSTEM_COMPONENT

@@ -99,7 +92,8 @@
 {
 	if (unlikely(in_interrupt())) 
 		BUG();
-	acpi_system_save_state(ACPI_STATE_S5);
+	pm_send_all(PM_SAVE_STATE, (void *)3);
+	pm_send_all(PM_SUSPEND, (void *)3);
 	acpi_enter_sleep_state_prep(ACPI_STATE_S5);
 	ACPI_DISABLE_IRQS();
 	acpi_enter_sleep_state(ACPI_STATE_S5);

Len, do you have any objection against this one ? BTW, did you get the previous one dedicated to SMP ? Here it is rediffed after this one, just in case :

diff -urN linux-2.4.26-pre2-pwoff/drivers/acpi/system.c linux-2.4.26-pre2-pwoff-smp/drivers/acpi/system.c

drivers/acpi/system.c +5 -0

@@ -40,6 +40,7 @@
 #include <asm/acpi.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
+#include <linux/sched.h>
 
 #ifdef CONFIG_ACPI_SLEEP
 #include <linux/mc146818rtc.h>

@@ -92,6 +93,10 @@
 {
 	if (unlikely(in_interrupt())) 
 		BUG();
+#ifdef CONFIG_SMP
+	/* Some SMP machines only can poweroff in boot CPU */
+	set_cpus_allowed(current, 1 << cpu_logical_map(0));
+#endif
 	pm_send_all(PM_SAVE_STATE, (void *)3);
 	pm_send_all(PM_SUSPEND, (void *)3);
 	acpi_enter_sleep_state_prep(ACPI_STATE_S5);

Cheers,
Willy

Signature · 1 line

Sérgio M. B.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Martin,
I first thought, that you went the right path, as you use a smp-system, to apply the mentioned patches for the smp-poweroff problem.
For my uni-processor (laptop) I had a different problem with poweroff, and a solution (patch):
http://bugme.osdl.org/show_bug.cgi?id=2183
Please do not be confused. Len thought, that it would be a dublicate to bug 2109, so I posted the patch there. Personally I don't think that the problems are the same, as they did start with different versions...but of the same file...
Ok. maybe you will have a try with my patch ("hwsleep.c revert part of v1.23 introduced cond. when S5") from 4th of march. I would think, that you will need the smp-patch anyway. But I am just guessing.

Cheers
hartwig

drivers/acpi/system.c 2004-03-08 09:36:19.813378040 +0800 acpi_power_off (void)

Quoted 11 lines · Martin Siegert

I tried to combine the two patches to apply to 2.4.25 and came up with

drivers/acpi/system.c Thu Mar 11 13:12:11 2004 renamed from drivers/acpi/system.c.orig Fri Nov 28 10:26:19 2003 +0 -0

@@ -40,6 +40,7 @@

@@ -95,6 +96,12 @@

drivers/acpi/system.c 2004-03-08 09:36:19.813378040 +0800 renamed from drivers/acpi/system.c 2004-03-08 09:29:30.925538440 +0800 +0 -0

@@ -40,6 +40,7 @@

@@ -95,6 +96,8 @@ acpi_power_off (void)

Gruß
hartwig felger

Hartwig Felger informatics

- --
1024D/339FD693 Hartwig Felger <[email protected]> Key fingerprint = FB2F 3EE9 345A D55B 6FF2 0EC1 F5B0 684F 339F D693 For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAUYsF9bBoTzOf1pMRAlOZAKCvbR65c3pmiQPVfw4ZAlrg6NizZQCgiJjr 58hnH6PxL8IZPmf0/nNKZ+U=
=raJH
-----END PGP SIGNATURE-----

If I issue a 'service acpid restart? to restart the acpid daemon, the applications assigned to the hotkeys are launched as supposed. However, in this case when I hit the powerbutton, the laptop immediately calls acpi_power_off and shuts down uncleanly without unmounting file systems or anything.

Thus wrote Mads Paulin:

Quoted 5 lines

If I issue a 'service acpid restart? to restart the acpid daemon, the applications assigned to the hotkeys are launched as supposed. However, in this case when I hit the powerbutton, the laptop immediately calls acpi_power_off and shuts down uncleanly without unmounting file systems or anything.

See what this 'service acpid restart' does, this must be a script of some sort.
Best regards,

Signature · 13 lines

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Acpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

it would appear that it (re)starts thet script in /etc/init.d/ called acpid. this in turn turns on the acpi even monitoring daemon.

At least thats what it does on my P2120 Debian/Testing machine.

TMC

Quoted 25 lines · Karol Kozimor

Thus wrote Mads Paulin:

Quoted 5 lines

If I issue a 'service acpid restart? to restart the acpid daemon, the applications assigned to the hotkeys are launched as supposed. However, in this case when I hit the powerbutton, the laptop immediately calls acpi_power_off and shuts down uncleanly without unmounting file systems or anything.

See what this 'service acpid restart' does, this must be a script of some sort.
Best regards,

Signature · 13 lines

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Acpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

- Correct - it just shuts down acpid and then starts it over again. I will look at the script and compare it to the old mandrake 9.1 scipt (which worked). My guess is that this is not a problem if the script, but rather the acpid daemon (if it has changed lately) or the newer

version of acpi used in my new kernel..

Thus wrote Mads Paulin:

Quoted 4 lines

- Correct - it just shuts down acpid and then starts it over again. I will look at the script and compare it to the old mandrake 9.1 scipt (which worked). My guess is that this is not a problem if the script, but rather the acpid daemon (if it has changed lately) or the newer

There were no substantial changes, as far as I know. However, it is likely that your event helper scripts have changed if you experience such a behaviour.

Quoted 1 line

version of acpi used in my new kernel..

Might be.
Best regards,

I have now tried to compare different acpi related scripts in mandrake 9.1 and 10.0.

Furthermore, I have investigated a little bit more.

the poweroff script is just a link to /sbin/halt. If I restart acpid and call halt myself, everything shuts down og.

If I restart acpid and pushes the powerbutton, the shutdown sequence is started, and the last thing output before poweroff is "Shutting down acpi daemon"

Don't know why this acpi event has something to do with the acpi daemon calling poweroff prematurely... ???