(cc stable) On Mon, 17 Aug 2009 14:43:34 +0200 Frans Pop <elendil@xxxxxxxxx> wrote: > If the BIOS reports an invalid throttling state (which seems to be > fairly common after system boot), a reset is done to state T0. > Because of a check in acpi_processor_get_throttling_ptc(), the reset > never actually gets executed, which results in the error reoccurring > on every access of for example /proc/acpi/processor/CPU0/throttling. > > Add a 'force' option to acpi_processor_set_throttling() to ensure > the reset really takes effect. > > http://bugzilla.kernel.org/show_bug.cgi?id=13389 > > Signed-off-by: Frans Pop <elendil@xxxxxxxxx> > Acked-by: Zhang Rui <rui.zhang@xxxxxxxxx> Unfortunately there are changes in linux-next which make this patch inapplicable in non-trivial ways. So we'll be needing one flavour of the patch for 2.6.30.x and 2.6.31.x (the patch you just sent) and a different flavour for 2.6.32. Or we preempt the pending linux-next changes and jam these patches into the tree first. > > This patch, together with the next one, fixes a regression introduced in > 2.6.30, listed on the regression list. They have been available for 2.5 > months now in bugzilla, but have not been picked up, despite various > reminders and without any reason given. > > Google shows that numerous people are hitting this issue. The issue is in > itself relatively minor, but the bug in the code is clear. > > The patches have been in all mu kernels and today testing has shown that > throttling works correctly with the patches applied when the system > overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14). OK, that sucks. Guys, what happened here? Fixing regressions surely is our number one hair-on-fire priority, yet the ACPI developers have found other things to be doing for two and a half months and now we have a mess on our hands. Did this just fall through the cracks or is there some problem? -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
