On Saturday, July 28, 2012 22:43:35 David Haller wrote:
Thermal throttling is done autonomously by the CPU.
Are you sure that the hardware is taking care of this or should the kernel instruct the CPU to do so ?
But, as you have a notebook and are stuck with your cooling system, check up on dusted up coolers / vents etc. Carefully clean the fans. Google for how to (suck vs. blow).
That is the first thing that I did, but I can't imagine that the amount of dust is automatically changing with the kernel ? Otherwise we should introduce a dustlevel to each kernel. But seriously, I have cleaned the cooling system already but I can see a very big difference in behaviour between the 3.3 kernel series and the 3.4/3.5 kernels. Even running for 30 seconds on full load causes a full shutdown of the notebook with a 3.4 kernel. With a 3.3 kernel I hear the fans spinning up and hot air is nicely blown out of the notebook without causing the shutdown effect. If I use the nocrt=1 for the thermal module on a 3.4 system, I am able to reproduce the normal behaviour of the 3.3 kernel. Without that option, the kernel throws a thermal exception and shuts down the notebook.
Anyway: having the CPU throttling itself on load is not "normal". Whether the load comes from cinebench, prime95, gcc, mencoder, folding@home, seti@home or whatever is irrelevant.
Well, this is what both the 3.4 and 3.5 kernels are doing. The maximum speed is lowered in order to reduce the temperature (I assume).
Once the CPU's are cool'ed down, this maximum speed should be increased again.
This is what kernel 3.5 kernel is not doing. The maximum speed is no longer increased. For me it is strange to see that this all started when the kernel developers made the changes to the cpufreq module. First we got the situation that it was not automatically loaded and now we see thermal issues. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org