http://bugzilla.kernel.org/show_bug.cgi?id=6519
------- Additional Comments From [EMAIL PROTECTED] 2006-05-15 11:01 -------
Progress: git bisect identified the following revision:
--------8<--------
2203d6ed448ff3b777ee6bb614a53e686b483e5b is first bad commit
diff-tree 2203d6ed448ff3b777ee6bb614a53e686b483e5b (from
2656c076e31a3ce3ab2a987a578e7122dc2af51d)
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Fri Nov 18 07:29:51 2005 -0800
Fix ACPI processor power block initialization
Properly clear the memory, and set "pr->flags.power" only if a C2 or
deeper state is valid (to make the code match both the comment and
previous behaviour).
This fixes a boot-time lockup reported by Maneesh Soni when using
"maxcpus=1".
Acked-by: Maneesh Soni <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
:040000 040000 52be621b960ae192b36acf778c966d78ff5edbe2
04c183ce141dab8cdff049c1dae379104b637ed4 M drivers
------------------------ drivers/acpi/processor_idle.c ------------------------
index 573b6a9..70d8a6e 100644
@@ -514,8 +514,6 @@ static int acpi_processor_set_power_poli
static int acpi_processor_get_power_info_fadt(struct acpi_processor *pr)
{
- int i;
-
ACPI_FUNCTION_TRACE("acpi_processor_get_power_info_fadt");
if (!pr)
@@ -524,8 +522,7 @@ static int acpi_processor_get_power_info
if (!pr->pblk)
return_VALUE(-ENODEV);
- for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
- memset(pr->power.states, 0, sizeof(struct acpi_processor_cx));
+ memset(pr->power.states, 0, sizeof(pr->power.states));
/* if info is obtained from pblk/fadt, type equals state */
pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
@@ -555,13 +552,9 @@ static int acpi_processor_get_power_info
static int acpi_processor_get_power_info_default_c1(struct acpi_processor *pr)
{
- int i;
-
ACPI_FUNCTION_TRACE("acpi_processor_get_power_info_default_c1");
- for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
- memset(&(pr->power.states[i]), 0,
- sizeof(struct acpi_processor_cx));
+ memset(pr->power.states, 0, sizeof(pr->power.states));
/* if info is obtained from pblk/fadt, type equals state */
pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
@@ -873,7 +866,8 @@ static int acpi_processor_get_power_info
for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
if (pr->power.states[i].valid) {
pr->power.count = i;
- pr->flags.power = 1;
+ if (pr->power.states[i].type >= ACPI_STATE_C2)
+ pr->flags.power = 1;
}
}
--------8<--------
The last change in the diff, in acpi_processor_get_power_info, is what makes the
difference: commenting out the "if (pr->power.states[i].type >= ACPI_STATE_C2)"
restores the power saving in 2.6.16.14 .
I know nothing about kernel internals so the following may not be well informed.
I'm inclined to think that the revision is not blameworthy in itself, but rather
exposes an underlying problem. The comment above this bit of code says, 'if one
state of type C2 or C3 is available, mark this CPU as being "idle manageable"'.
As the commit log says, the revision makes the code match the comment.
What happens in my case is revealed after enabling some debug statements:
--------8<--------
acpi_processor-0926 [07] processor_get_power_in: ----Entry
acpi_processor-0621 [08] processor_get_power_in: ----Entry
acpi_processor-0634 [08] processor_get_power_in: ----Exit- 0000000000000000
acpi_processor-0646 [08] processor_get_power_in: ----Entry
acpi_processor-0660 [08] processor_get_power_in: No _CST, giving up
acpi_processor-0661 [08] processor_get_power_in: ----Exit- FFFFFFFFFFFFFFED
acpi_processor-0582 [08] processor_get_power_in: ----Entry
acpi_processor-0614 [08] processor_get_power_in: lvl2[0x00004014]
lvl3[0x00004015]
acpi_processor-0616 [08] processor_get_power_in: ----Exit- 0000000000000000
acpi_processor-0774 [08] processor_power_verify: ----Entry
acpi_processor-0785 [08] processor_power_verify: latency too large [101]
acpi_processor-0786 [08] processor_power_verify: ----Exit-
acpi_processor-0804 [08] processor_power_verify: ----Entry
acpi_processor-0815 [08] processor_power_verify: latency too large [1001]
acpi_processor-0816 [08] processor_power_verify: ----Exit-
acpi_processor-0511 [08] processor_set_power_po: ----Entry
acpi_processor-0577 [08] processor_set_power_po: ----Exit- 0000000000000000
acpi_processor-0963 [07] processor_get_power_in: ----Exit- 0000000000000000
ACPI: CPU0 (power states: C1[C1])
--------8<--------
So in acpi_processor_get_power_info, acpi_processor_get_power_info_cst fails and
acpi_processor_get_power_info_fadt is called. The latter finds states C2 and C3
but assigns latencies which, suspiciously, are each 1 greater than the
permissible maximum. Would these be dummy values that get inserted when genuine
values could not be read?
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
