Some comments...: On Saturday 07 March 2009 06:39:40 am Andrew Morton wrote: > On Sat, 7 Mar 2009 05:18:52 +0000 Matthew Garrett <mjg@xxxxxxxxxx> wrote: > > On Fri, Mar 06, 2009 at 08:46:07PM -0800, Andrew Morton wrote: > > > On Sat, 7 Mar 2009 04:38:57 +0000 Matthew Garrett <mjg@xxxxxxxxxx> wrote: > > > > Resulting in computers that run slower and consume more power. "My > > > > script that does something stupid now gives an error" isn't a > > > > regression. "My computer now overheats" is a bug that was being > > > > hidden in the first place. Why don't we just fix that bug? > > > > > > Do the thing which I suggested, and which you deleted without comment. > > > > As I said, we can't print a warning without either special casing > > p4-clockmod in the core > > That patch already special-cased p4-clockmod in the core. > > > or adding code to every driver that will only be > > relevant for p4-clockmod. It also means another 6 months of computers > > running slower and consuming more power. > > Special-casing p4-clockmod will not affect other drivers. > > > > Or something else! Just don't break existing userspace code, and > > > people's computers. I'm sure you can manage this. Any modification on the p4-clockmod driver is not much worth it as it is broken by design. If you really touch it, please do it properly: - move it to drivers/platforms/x86/native_throttling.c - let it register at the generic thermal zone code as a cooling device - make sure it only loads if acpi throttling does not get activated This is what you want. Going the "a cpufreq driver automatically is a cooling device, let's use it" and then cut out the cpufreq capabilities: --------- [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor. The latency of p4-clockmod sucks so hard that scaling on a regular basis with ondemand is a really bad idea. Signed-off-by: Matthew Garrett <mjg59@xxxxxxxxxxxxx> --------- is making things worse not better. Until this happened, please mark the p4-clockmod driver experimental, throw out all references to the cpufreq list and best state at load time that it should only be used on broken BIOSes. Thomas -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html