Machine shutdown after resume from S3

DISCUSSION Herton Ronaldo Krzesinski 3 participants 6 messages Feb 20, 2008 – Feb 21, 2008 ACPI

Share & tools

Herton Ronaldo Krzesinski

author

2008-02-20 21:37 UTC #0 lore raw

I have here an Intel Classmate hardware sample, and I have a weird problem with suspend to ram, the machine does a power off when resuming.

I isolated the problem to the button acpi module, without loading it (or just removing it before doing a s2ram) I don't get the problem. In the specific machine I have here I can only resume it pressing the power button, so I think this is related.

I started looking into the kernel code and did some tests. The first thing I tried just as a test was to disable the code in acpi_button_notify function. As expected it stopped to send the power button key events
to /proc/acpi/event, but I still got the same s2ram issues. But if I disable acpi_install_fixed_event_handler calls in acpi_button_install_notify_handlers the power off issue in s2ram was gone, of course also with power button not notifying anything anymore :), but this was just a test.

After this tests then I went further to try to track down the problem and I saw acpi_ev_fixed_event_dispatch, that is the function that will call acpi_button_notify_fixed. First thing I noted: the comment about acpi_ev_fixed_event_dispatch says it will return INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED, but acpi_button_notify_fixed return AE_OK, is this right (comment is outdated) or am I missing something? Anyway I changed AE_OK to ACPI_INTERRUPT_HANDLED but this didn't change nothing. In the end I stopped there, doesn't seem to be anything wrong with the code at all, I also took a look at acpi_ev_fixed_event_detect and other code related to the table of fixed events (acpi_gbl_fixed_event_handlers), but didn't got more clues. Could be this a bios issue, or there is some hints to what I can try to look and prove that it's bios or code related?

PS.: with netconsole I don't get any message before power off after resume, I tried it to get more hints.

--
[]'s
Herton

Andrey Borzenkov

2008-02-21 17:57 UTC #1 lore raw

Quoted 3 lines · Herton Ronaldo Krzesinski

I have here an Intel Classmate hardware sample, and I have a weird problem with suspend to ram, the machine does a power off when resuming.

Do you have acpid running? You may also be interested in this:
http://qa.mandriva.com/show_bug.cgi?id=18998
http://qa.mandriva.com/show_bug.cgi?id=23296
http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup

Quoted 5 lines

I isolated the problem to the button acpi module, without loading it (or just removing it before doing a s2ram) I don't get the problem. In the specific machine I have here I can only resume it pressing the power button, so I think this is related.

IIRC the issue was that button press that triggered resume was reported to user space. This apparently was fixed in the quoted patch; but may be this specific model goes via different code path?

Quoted 32 lines

I started looking into the kernel code and did some tests. The first thing I tried just as a test was to disable the code in acpi_button_notify function. As expected it stopped to send the power button key events to /proc/acpi/event, but I still got the same s2ram issues. But if I disable acpi_install_fixed_event_handler calls in acpi_button_install_notify_handlers the power off issue in s2ram was gone, of course also with power button not notifying anything anymore :), but this was just a test.
After this tests then I went further to try to track down the problem and I saw acpi_ev_fixed_event_dispatch, that is the function that will call acpi_button_notify_fixed. First thing I noted: the comment about acpi_ev_fixed_event_dispatch says it will return INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED, but acpi_button_notify_fixed return AE_OK, is this right (comment is outdated) or am I missing something? Anyway I changed AE_OK to ACPI_INTERRUPT_HANDLED but this didn't change nothing. In the end I stopped there, doesn't seem to be anything wrong with the code at all, I also took a look at acpi_ev_fixed_event_detect and other code related to the table of fixed events (acpi_gbl_fixed_event_handlers), but didn't got more clues. Could be this a bios issue, or there is some hints to what I can try to look and prove that it's bios or code related?
PS.: with netconsole I don't get any message before power off after resume, I tried it to get more hints.
--
[]'s
Herton
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Andrey Borzenkov

2008-02-21 18:43 UTC #2 lore raw

Quoted 4 lines · Andrey Borzenkov

Quoted 2 lines · Herton Ronaldo Krzesinski
I have here an Intel Classmate hardware sample, and I have a weird problem with suspend to ram,

wait a bit; suspend to RAM is S1 not S3. The mentined patch explicitly checks for S3 state and prevents power button event from reaching user space; but you are resuming from *S1*.

Looks like this requires some sort of quirks to recognize this specific platform and apply the same workaround to S1.

Quoted 57 lines

Quoted 2 lines
the machine does a power off when resuming.
Do you have acpid running? You may also be interested in this:
http://qa.mandriva.com/show_bug.cgi?id=18998
http://qa.mandriva.com/show_bug.cgi?id=23296
http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup
Quoted 5 lines
I isolated the problem to the button acpi module, without loading it (or just removing it before doing a s2ram) I don't get the problem. In the specific machine I have here I can only resume it pressing the power button, so I think this is related.
IIRC the issue was that button press that triggered resume was reported to user space. This apparently was fixed in the quoted patch; but may be this specific model goes via different code path?
Quoted 25 lines
I started looking into the kernel code and did some tests. The first thing I tried just as a test was to disable the code in acpi_button_notify function. As expected it stopped to send the power button key events to /proc/acpi/event, but I still got the same s2ram issues. But if I disable acpi_install_fixed_event_handler calls in acpi_button_install_notify_handlers the power off issue in s2ram was gone, of course also with power button not notifying anything anymore :), but this was just a test.
After this tests then I went further to try to track down the problem and I saw acpi_ev_fixed_event_dispatch, that is the function that will call acpi_button_notify_fixed. First thing I noted: the comment about acpi_ev_fixed_event_dispatch says it will return INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED, but acpi_button_notify_fixed return AE_OK, is this right (comment is outdated) or am I missing something? Anyway I changed AE_OK to ACPI_INTERRUPT_HANDLED but this didn't change nothing. In the end I stopped there, doesn't seem to be anything wrong with the code at all, I also took a look at acpi_ev_fixed_event_detect and other code related to the table of fixed events (acpi_gbl_fixed_event_handlers), but didn't got more clues. Could be this a bios issue, or there is some hints to what I can try to look and prove that it's bios or code related?
PS.: with netconsole I don't get any message before power off after resume, I tried it to get more hints.
Quoted 7 lines
--
[]'s
Herton
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Matthew Garrett

2008-02-21 19:03 UTC #3 lore raw

Quoted 1 line · Andrey Borzenkov

wait a bit; suspend to RAM is S1 not S3.

Not on any even vaguely modern hardware, no. In any case, the Classmate reboots before entering userspace.

Signature · 1 line

Matthew Garrett | [email protected]

Andrey Borzenkov

2008-02-21 19:45 UTC #4 lore raw

Quoted 5 lines · Matthew Garrett

Quoted 1 line · Andrey Borzenkov
wait a bit; suspend to RAM is S1 not S3.
Not on any even vaguely modern hardware, no.

Yes, shame on me; I should not be doing several things at once.

Herton Ronaldo Krzesinski

author

2008-02-21 22:21 UTC #5 lore raw

In reply to Andrey Borzenkov

Em Thursday 21 February 2008 14:46:45 Andrey Borzenkov escreveu:

Quoted 18 lines

Quoted 3 lines · Herton Ronaldo Krzesinski
I have here an Intel Classmate hardware sample, and I have a weird problem with suspend to ram, the machine does a power off when resuming.
Do you have acpid running? You may also be interested in this:
http://qa.mandriva.com/show_bug.cgi?id=18998
http://qa.mandriva.com/show_bug.cgi?id=23296
http://article.gmane.org/gmane.linux.acpi.devel/17581/match=sup
Quoted 5 lines
I isolated the problem to the button acpi module, without loading it (or just removing it before doing a s2ram) I don't get the problem. In the specific machine I have here I can only resume it pressing the power button, so I think this is related.

Quoted 3 lines

IIRC the issue was that button press that triggered resume was reported to user space. This apparently was fixed in the quoted patch; but may be this specific model goes via different code path?

In my case here is not an userspace issue. But the patch in the last link you posted gave me an idea, to check code executed in resume, I managed to make a quick hack that solved the issue:

drivers/acpi/sleep/main.c +2 -0

index 293a1cb..2255434 100644
@@ -156,6 +156,8 @@ static int acpi_pm_enter(suspend_state_t pm_state)
 
 	local_irq_save(flags);
 	acpi_enable_wakeup_device(acpi_state);
+	(void) acpi_set_register(acpi_gbl_fixed_event_info[ACPI_EVENT_POWER_BUTTON].enable_register_id, 0);
+	(void) acpi_set_register(acpi_gbl_fixed_event_info[ACPI_EVENT_POWER_BUTTON].status_register_id, 0);
 	switch (acpi_state) {
 	case ACPI_STATE_S1:
 		barrier();

For some reason with this I don't have the power off problem in resume. I'll try to check more the code and acpi spec, but does this could indicate a bug in bios?

--
[]'s
Herton