ACPI power down problem

DISCUSSION Stephan Seidl 2 participants 4 messages Dec 7, 2007 – Dec 13, 2007 ACPI

Share & tools

Stephan Seidl

author

2007-12-07 02:04 UTC #0 lore raw

Hi,
I would like to ask two questions, but firstly some history. Normally Debian Sarge is running with the kernel 2.6.14.3 with several patches and all works fine since Dec 2005. In Jul, 2006, I tried another kernel, 2.6.17.4, again with several patches, and again all worked fine with the exception of the fact that the machine did not switch off the power on `/sbin/shutdown -t5 -h -P now'. So I rejected the kernel 2.6.17.4 hoping that the problems would disappear by itself with the time. But, it did not.
In Aug 2007, Debian 4.0 r1 appeared with a kernel 2.6.18..., still having the power down problem. Obviously, the problem has been introduced between 2.6.14.3 and 2.6.17.4 and I am the only who has it. The concerning board can be described by

Award Medallion BIOS v6.0, An Energy Star Ally
ASUS P4B ACPI BIOS Revision 1013 Beta 004
Award Plug and Play BIOS Extension v1.0A

This week, to tackle the problem, I addionally applied the patches in the attachment to have the console messages somewhat longer on the screen. I got the same output with the two kernels, 2.6.14.3 and 2.6.17.4, namely

Power down.
acpi_power_off called
hwsleep-0284 [01] enter_sleep_state : Entering sleep state [S5]

whereat the line numer 0284 changed to 0283 for 2.6.17.4.
What in fact happens after the above has been seen for 20 seconds is that the same machine switches off in case of 2.6.14.3, and wrongly reboots in case of 2.6.17.4. Now the questions, firstly,
is that a kernel bug ? From my point of view, yes, it seems to be one. Secondly, if I would more or less stupidly put the debugging into execution, is there anyone who could guide me, because in the ACPI kernel environment, I am mildly expressed blind.
Many thanks in advance
Stephan

diff -crN -C 7 linux-2.6.14.3-ORG/drivers/acpi/hardware/hwsleep.c linux-2.6.14.3/drivers/acpi/hardware/hwsleep.c
*** linux-2.6.14.3-ORG/drivers/acpi/hardware/hwsleep.c Thu Nov 24 23:10:21 2005
--- linux-2.6.14.3/drivers/acpi/hardware/hwsleep.c Thu Dec 6 16:00:51 2007
***************
*** 279,292 ****
--- 279,300 ----
ACPI_REGISTER_PM1_CONTROL, &PM1Acontrol);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
ACPI_DEBUG_PRINT((ACPI_DB_INIT,
"Entering sleep state [S%d]\n", sleep_state));

+ {
+ volatile int n = 2000, m = 0, i, j, k;
+ for (i = 0; i < n; i++)
+ for (j = 0; j < n; j++)
+ for (k = 0; k < n; k++)
+ m = 1 - m;
+ }
+
/* Clear SLP_EN and SLP_TYP fields */

  	PM1Acontrol &= ~(sleep_type_reg_info->access_bit_mask |
  			 sleep_enable_reg_info->access_bit_mask);
  	PM1Bcontrol = PM1Acontrol;

/* Insert SLP_TYP bits */

diff -crN -C 7 linux-2.6.17.4-ORG/drivers/acpi/hardware/hwsleep.c linux-2.6.17.4/drivers/acpi/sleep/hardware/hwsleep.c
*** linux-2.6.17.4-ORG/drivers/acpi/hardware/hwsleep.c Thu Jul 6 22:02:28 2006
--- linux-2.6.17.4/drivers/acpi/hardware/hwsleep.c Wed Dec 5 16:37:33 2007
***************
*** 278,291 ****
--- 278,299 ----
ACPI_REGISTER_PM1_CONTROL, &PM1Acontrol);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
ACPI_DEBUG_PRINT((ACPI_DB_INIT,
"Entering sleep state [S%d]\n", sleep_state));

+ {
+ volatile int n = 2000, m = 0, i, j, k;
+ for (i = 0; i < n; i++)
+ for (j = 0; j < n; j++)
+ for (k = 0; k < n; k++)
+ m = 1 - m;
+ }
+
/* Clear SLP_EN and SLP_TYP fields */

  	PM1Acontrol &= ~(sleep_type_reg_info->access_bit_mask |
  			 sleep_enable_reg_info->access_bit_mask);
  	PM1Bcontrol = PM1Acontrol;

/* Insert SLP_TYP bits */

Len Brown

reviewer

2007-12-07 03:51 UTC #1 lore raw

Quoted 26 lines · Stephan Seidl

Hi,
I would like to ask two questions, but firstly some history. Normally Debian Sarge is running with the kernel 2.6.14.3 with several patches and all works fine since Dec 2005. In Jul, 2006, I tried another kernel, 2.6.17.4, again with several patches, and again all worked fine with the exception of the fact that the machine did not switch off the power on `/sbin/shutdown -t5 -h -P now'. So I rejected the kernel 2.6.17.4 hoping that the problems would disappear by itself with the time. But, it did not.
In Aug 2007, Debian 4.0 r1 appeared with a kernel 2.6.18..., still having the power down problem. Obviously, the problem has been introduced between 2.6.14.3 and 2.6.17.4 and I am the only who has it. The concerning board can be described by
Award Medallion BIOS v6.0, An Energy Star Ally
ASUS P4B ACPI BIOS Revision 1013 Beta 004
Award Plug and Play BIOS Extension v1.0A
This week, to tackle the problem, I addionally applied the patches in the attachment to have the console messages somewhat longer on the screen. I got the same output with the two kernels, 2.6.14.3 and 2.6.17.4, namely
Power down.
acpi_power_off called
hwsleep-0284 [01] enter_sleep_state : Entering sleep state [S5]

Quoted 7 lines

whereat the line numer 0284 changed to 0283 for 2.6.17.4.
What in fact happens after the above has been seen for 20 seconds is that the same machine switches off in case of 2.6.14.3, and wrongly reboots in case of 2.6.17.4. Now the questions, firstly,
is that a kernel bug ? From my point of view, yes, it seems to be one. Secondly, if I would more or less stupidly put the debugging into execution, is there anyone who could guide me, because in the ACPI kernel environment,

yes, it is a bug.
please try linux-2.6.23.stable and see if it still resets on poweroff there.

see if there is any difference when you boot with "maxcpus=1".

cheers,
-Len

Stephan Seidl

author

2007-12-12 23:09 UTC #2 lore raw

Dear Len,
2.6.17.4 with "maxcpus=1" does not switch off the power (still bad). 2.6.23.9 does switch off the power (works fine).
So I am not sure what should be the next step,
perhaps a simple Debian bug report.
Regards,
Stephan

Quoted 43 lines · Len Brown

Quoted 26 lines · Stephan Seidl
Hi,
I would like to ask two questions, but firstly some history. Normally Debian Sarge is running with the kernel 2.6.14.3 with several patches and all works fine since Dec 2005. In Jul, 2006, I tried another kernel, 2.6.17.4, again with several patches, and again all worked fine with the exception of the fact that the machine did not switch off the power on `/sbin/shutdown -t5 -h -P now'. So I rejected the kernel 2.6.17.4 hoping that the problems would disappear by itself with the time. But, it did not.
In Aug 2007, Debian 4.0 r1 appeared with a kernel 2.6.18..., still having the power down problem. Obviously, the problem has been introduced between 2.6.14.3 and 2.6.17.4 and I am the only who has it. The concerning board can be described by
Award Medallion BIOS v6.0, An Energy Star Ally
ASUS P4B ACPI BIOS Revision 1013 Beta 004
Award Plug and Play BIOS Extension v1.0A
This week, to tackle the problem, I addionally applied the patches in the attachment to have the console messages somewhat longer on the screen. I got the same output with the two kernels, 2.6.14.3 and 2.6.17.4, namely
Power down.
acpi_power_off called
hwsleep-0284 [01] enter_sleep_state : Entering sleep state [S5]
Quoted 7 lines
whereat the line numer 0284 changed to 0283 for 2.6.17.4.
What in fact happens after the above has been seen for 20 seconds is that the same machine switches off in case of 2.6.14.3, and wrongly reboots in case of 2.6.17.4. Now the questions, firstly,
is that a kernel bug ? From my point of view, yes, it seems to be one. Secondly, if I would more or less stupidly put the debugging into execution, is there anyone who could guide me, because in the ACPI kernel environment,
yes, it is a bug.
please try linux-2.6.23.stable and see if it still resets on poweroff there.
see if there is any difference when you boot with "maxcpus=1".
cheers,
-Len

Len Brown

reviewer

2007-12-13 21:13 UTC #3 lore raw

Quoted 5 lines · Stephan Seidl

Dear Len,
2.6.17.4 with "maxcpus=1" does not switch off the power (still bad). 2.6.23.9 does switch off the power (works fine).
So I am not sure what should be the next step,
perhaps a simple Debian bug report.

Yes, since latest upstream stable kernel works fine, it is a debian specific (and/or old upstream) issue.

You might try some of the older upstream kernels to give the debian folks an idea of how much newer than 2.6.18 they need to go to get the fix.

thanks,
-Len

Quoted 49 lines · Len Brown

Quoted 35 lines · Stephan Seidl
Quoted 26 lines
Hi,
I would like to ask two questions, but firstly some history. Normally Debian Sarge is running with the kernel 2.6.14.3 with several patches and all works fine since Dec 2005. In Jul, 2006, I tried another kernel, 2.6.17.4, again with several patches, and again all worked fine with the exception of the fact that the machine did not switch off the power on `/sbin/shutdown -t5 -h -P now'. So I rejected the kernel 2.6.17.4 hoping that the problems would disappear by itself with the time. But, it did not.
In Aug 2007, Debian 4.0 r1 appeared with a kernel 2.6.18..., still having the power down problem. Obviously, the problem has been introduced between 2.6.14.3 and 2.6.17.4 and I am the only who has it. The concerning board can be described by
Award Medallion BIOS v6.0, An Energy Star Ally
ASUS P4B ACPI BIOS Revision 1013 Beta 004
Award Plug and Play BIOS Extension v1.0A
This week, to tackle the problem, I addionally applied the patches in the attachment to have the console messages somewhat longer on the screen. I got the same output with the two kernels, 2.6.14.3 and 2.6.17.4, namely
Power down.
acpi_power_off called
hwsleep-0284 [01] enter_sleep_state : Entering sleep state [S5]
Quoted 7 lines
whereat the line numer 0284 changed to 0283 for 2.6.17.4.
What in fact happens after the above has been seen for 20 seconds is that the same machine switches off in case of 2.6.14.3, and wrongly reboots in case of 2.6.17.4. Now the questions, firstly,
is that a kernel bug ? From my point of view, yes, it seems to be one. Secondly, if I would more or less stupidly put the debugging into execution, is there anyone who could guide me, because in the ACPI kernel environment,
Quoted 8 lines
yes, it is a bug.
please try linux-2.6.23.stable and see if it still resets on poweroff there.
see if there is any difference when you boot with "maxcpus=1".
cheers,
-Len
-
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