Latest working kernel version: 2.6.24 Earliest failing kernel version: 2.6.25 Distribution: None Hardware Environment: X86_64 Software Environment: pure 64-bit software Problem Description: Starting with 2.6.25, my CPU temperatures are reported as 55C when idle (30C in 2.6.24). Load avg stays over 0.5 even when completely idle, and mpg123 takes 38% of cpu when it took 3% in 2.6.24 (from top). While the temperature readings of coretemp might be wrong in all kernels, afterall .24 claims using undocumented features and .25-.28 claim to use a relative scale, the cpu usage of all processes has greatly increased starting with .25 kernel. I have tried various configs with .25, .26, and .28, both identical with my .24 config and variations such as enabling tickless, hpet, and using different IO schedulers etc. No matter the config, all kernels starting .25 show this huge cpu usage in all processes. I'm not at all sure what causes this, so marking as platform-specific. Pentium Dual Core E2160 overclocked to 3Ghz Steps to reproduce: Boot a 64-bit kernel 2.6.25 or later
Created attachment 19654 [details] Working config from .24
Created attachment 19655 [details] Current config of .28
Created attachment 19656 [details] dmesg from .28 boot
Adding that when idling in bios the bios shows cpu temps of 30C
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 5 Jan 2009 03:22:43 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12362 > > Summary: Extremely high cpu usage and temps starting 2.6.25 > Product: Platform Specific/Hardware > Version: 2.5 > KernelVersion: 2.6.28 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: x86-64 > AssignedTo: platform_x86_64@kernel-bugs.osdl.org > ReportedBy: curaga@operamail.com > > > Latest working kernel version: 2.6.24 > Earliest failing kernel version: 2.6.25 (regression) > Distribution: None > Hardware Environment: X86_64 > Software Environment: pure 64-bit software > Problem Description: Starting with 2.6.25, my CPU temperatures are reported > as > 55C when idle (30C in 2.6.24). Load avg stays over 0.5 even when completely > idle, and mpg123 takes 38% of cpu when it took 3% in 2.6.24 (from top). > > While the temperature readings of coretemp might be wrong in all kernels, > afterall .24 claims using undocumented features and .25-.28 claim to use a > relative scale, the cpu usage of all processes has greatly increased starting > with .25 kernel. > > I have tried various configs with .25, .26, and .28, both identical with my > .24 > config and variations such as enabling tickless, hpet, and using different IO > schedulers etc. No matter the config, all kernels starting .25 show this huge > cpu usage in all processes. > > I'm not at all sure what causes this, so marking as platform-specific. > > Pentium Dual Core E2160 overclocked to 3Ghz > > Steps to reproduce: Boot a 64-bit kernel 2.6.25 or later > So I take it that you beleive that this regression was added into drivers/hwmon/coretemp.c during 2.6.25 development? If so, possible culprits would be: commit 561d9a969455cb009bb15b63e1d925dc527e7a9d Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Mon Dec 3 18:01:50 2007 +0100 HWMON: coretemp, suspend fix commit 6369a2887a1b35fde91573adc650528e3efea8e9 Author: Rudolf Marek <r.marek@assembler.cz> Date: Fri Jan 18 00:42:54 2008 +0100 hwmon: (coretemp) Add maximum cooling temperature readout commit 118a88718886a6cb7fb2cf7fb77ef2eea30c73a1 Author: Rudolf Marek <r.marek@assembler.cz> Date: Sun Feb 17 22:59:39 2008 +0100 hwmon: (coretemp) Add TjMax detection for mobile CPUs commit ae770152c801f10a91e5e86597a39b5f9ccf2d0d Author: Rudolf Marek <r.marek@assembler.cz> Date: Fri Jan 18 00:50:04 2008 +0100 hwmon: (coretemp) Add Penryn CPU to coretemp commit 34c86c1e622ec77ba81c01969003bbc8e15156f3 Author: Darrick J. Wong <djwong@us.ibm.com> Date: Fri Aug 15 00:40:41 2008 -0700 coretemp: recognize Nehalem CPUs None of which look very likely :(
> (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Mon, 5 Jan 2009 03:22:43 -0800 (PST) > bugme-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=12362 > > > > Summary: Extremely high cpu usage and temps starting 2.6.25 > > Product: Platform Specific/Hardware > > Version: 2.5 > > KernelVersion: 2.6.28 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: x86-64 > > AssignedTo: platform_x86_64@kernel-bugs.osdl.org > > ReportedBy: curaga@operamail.com > > > > > > Latest working kernel version: 2.6.24 > > Earliest failing kernel version: 2.6.25 > > (regression) > > > Distribution: None > > Hardware Environment: X86_64 > > Software Environment: pure 64-bit software > > Problem Description: Starting with 2.6.25, my CPU temperatures > > are reported as > > 55C when idle (30C in 2.6.24). Load avg stays over 0.5 even when completely > > idle, and mpg123 takes 38% of cpu when it took 3% in 2.6.24 (from top). > > > > While the temperature readings of coretemp might be wrong in all kernels, > > afterall .24 claims using undocumented features and .25-.28 claim to use a > > relative scale, the cpu usage of all processes has greatly increased > starting > > with .25 kernel. > > > > I have tried various configs with .25, .26, and .28, both > > identical with my .24 > > config and variations such as enabling tickless, hpet, and using different > IO > > schedulers etc. No matter the config, all kernels starting .25 show this > huge > > cpu usage in all processes. > > > > I'm not at all sure what causes this, so marking as platform-specific. > > > > Pentium Dual Core E2160 overclocked to 3Ghz > > > > Steps to reproduce: Boot a 64-bit kernel 2.6.25 or later > > > > So I take it that you beleive that this regression was added into > drivers/hwmon/coretemp.c during 2.6.25 development? > > If so, possible culprits would be: > > > commit 561d9a969455cb009bb15b63e1d925dc527e7a9d > Author: Rafael J. Wysocki <rjw@sisk.pl> > Date: Mon Dec 3 18:01:50 2007 +0100 > > HWMON: coretemp, suspend fix > > commit 6369a2887a1b35fde91573adc650528e3efea8e9 > Author: Rudolf Marek <r.marek@assembler.cz> > Date: Fri Jan 18 00:42:54 2008 +0100 > > hwmon: (coretemp) Add maximum cooling temperature readout > > commit 118a88718886a6cb7fb2cf7fb77ef2eea30c73a1 > Author: Rudolf Marek <r.marek@assembler.cz> > Date: Sun Feb 17 22:59:39 2008 +0100 > > hwmon: (coretemp) Add TjMax detection for mobile CPUs > > commit ae770152c801f10a91e5e86597a39b5f9ccf2d0d > Author: Rudolf Marek <r.marek@assembler.cz> > Date: Fri Jan 18 00:50:04 2008 +0100 > > hwmon: (coretemp) Add Penryn CPU to coretemp > > commit 34c86c1e622ec77ba81c01969003bbc8e15156f3 > Author: Darrick J. Wong <djwong@us.ibm.com> > Date: Fri Aug 15 00:40:41 2008 -0700 > > coretemp: recognize Nehalem CPUs > > > None of which look very likely :( Hello Sorry, I'm not sure if this is one regression or two. Either there is something that keeps my cpu a lot warmer, either by itself or by causing all processes to take more cpu, or there is that, and the temperature is read wrong. I took a look at the kernelnewbies changelog for .25, but nothing jumped at me as possible causes for either of the symptoms. I'm afraid doing a git bisect would be way beyond my skills. Also, the huge cpu-usage was at it's worst in .25, it is smaller in .28 but still there (the 38% is from .28, I think it was over 50% in .25) - Lauri
Looking for regression in the coretemp driver is barking up the wrong tree. That driver is _reporting_ the higher temperature usage, it's not causing it. It is possible that the reported temperature has shifted up by 15 degrees C between 2.6.24 and 2.6.25 (this can be seen with max temperature changing from 85 degrees C to 100 degrees C - is it the case?) But here the reported difference is 25 degrees C, so that can't be the sole cause. And the differences in reported CPU usage make it pretty clear that there is a real problem and it's not only a matter of temperature reporting. So I seriously doubt this has anything to do with lm-sensors.
Closing as obsolete, please update the bug if this is incorrect