http://bugzilla.kernel.org/show_bug.cgi?id=6519
------- Additional Comments From [EMAIL PROTECTED] 2006-05-15 11:18 ------- Pretty good for a Luddite - thanks. I've added Linus to cc, which means that this discussion should proceed via email, please. Just do a reply-to-all, make sure that [EMAIL PROTECTED] remains on cc. [EMAIL PROTECTED] wrote: > > 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. ------- 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
