Subject : 2.6.29-rcX: wierd iteractions with CPUFREQ Submitter : Dmitry Torokhov <dmitry.torokhov@gmail.com> Date : 2009-03-19 5:57 References : http://marc.info/?l=linux-kernel&m=123744265002098&w=4 This entry is being used for tracking a regression from 2.6.28. Please don't close it until the problem is fixed in the mainline.
Can you confirm going back to older kernels goes back to the old behaviour ? If so which rc did it break ?
Hi, Dmitry Will you please attach the output of acpidump, dmesg? It will be great if you can verify what Alan said in comment #1. Thanks.
please verify if this is a duplicate of bug #12830
sorry, it's not. on this laptop, the problem is that no ACPI events when overheating, which results in a low cpu frequency.
> acpi_processor_ppc_has_changed this is the BIOS instructing us to run slower, so AFAICS we are doing the right thing. We've seen several machines with BIOS that use PPC update to manage thermals, eg the T60. What box is this, and where is its acpidump? Did it not heat up in previous releases? Is the fan spinning at full speed when this happens? (has it recently become clogged?)
ping Dmitry.
Ignore me, please. It was indeed _PPC silently limiting the frequency, apparently because nvidia chip is overheating. Nothing to do with 2.6.29 except that I was trying to go off binary module and back to free nv driver at the same time and apparently nv keeps the chip at max performance at all times.