Re: Machine shutdown after resume from S3
Herton Ronaldo Krzesinski wrote: 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 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? 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 - 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
Re: Machine shutdown after resume from S3
Andrey Borzenkov wrote: Herton Ronaldo Krzesinski wrote: 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. 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 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? 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 - 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
Re: Machine shutdown after resume from S3
On Thu, Feb 21, 2008 at 09:43:30PM +0300, Andrey Borzenkov wrote: 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. -- Matthew Garrett | [EMAIL PROTECTED] - 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
Re: Machine shutdown after resume from S3
Matthew Garrett wrote: On Thu, Feb 21, 2008 at 09:43:30PM +0300, Andrey Borzenkov wrote: 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. - 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
Re: Machine shutdown after resume from S3
Em Thursday 21 February 2008 14:46:45 Andrey Borzenkov escreveu:
Herton Ronaldo Krzesinski wrote:
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
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?
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:
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 293a1cb..2255434 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -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
-
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
