Hello,
thanks for the inputs.
On Mon, Nov 01, 2010 at 08:58:28AM +0100, Heinz Diehl wrote:
On 31.10.2010, Oliver Kullmann wrote:
I'm here experiencing an alarming problem (not just KDE or so, but the kernel): I have a laptop with a quadcore i5 processor, but the system doesn't want to use it!
You maybe could be affected by this phenomenon here: https://bugzilla.kernel.org/show_bug.cgi?id=19702
Actually, frequency doesn't seem to be a (big) problem. Actually, yesterday for the first time it got stuck at 1.2 GHz (scheme "performance" regarding cpu-frequency), but switching to "on demand" got it back on track (switching for each core between 1.2 GHz and 2.4 GHz). So there is something wrong, but by just toggling the modes it seems fixable.
Regarding the usage of all four cores: NOW, as I had it a week ago, it runs fine again: Using all four cores as required (independent of the frequency). And, again, Bubblemoon shows correct (that is, sensible) cpu temperature. Could it be that if the temperature sensor doesn't work properly, then the system "hesitates" to use all cores, and after some time the system "warms up", the temperature sensor starts working, and all cores are being used?
Here is the data for the various outputs (the frequency shown is currently 1.2GHz, since I run on battery):
------------------------------------------------------
rpm -qa kernel* kernel-default-2.6.34.7-0.5.1.x86_64 kernel-desktop-2.6.34.7-0.5.1.x86_64 kernel-firmware-20100617-2.2.noarch
cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping : 5 cpu MHz : 1199.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping : 5 cpu MHz : 1199.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.05 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping : 5 cpu MHz : 1199.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.04 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz stepping : 5 cpu MHz : 1199.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 4788.02 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
cat /etc/SuSE-release openSUSE 11.3 (x86_64) VERSION = 11.3
kullmann-0:~> uname --all Linux linux-ubd8.site 2.6.34.7-0.5-desktop #1 SMP PREEMPT 2010-10-25 08:40:12 +0200 x86_64 x86_64 x86_64 GNU/Linux
-----------------------------------------------------------
thanks again
Oliver
You may be talking about different (albeit inter-related) things - throttling, temperature, and core threading. You may be seeing the effects of either the kernel's interaction with the cpu's throttling mechanism, the bios ACPI, or KDE's power management application. With throttling enabled, the cpu will respond to demand by increasing the voltage which will in turn increase the temperature. You indicated in your first post that you "need full power"; if so but you also want to conserve battery, then "ondemand" is the correct scaling policy. You should expect to see the processors throttled down unless the cpu needs more power to perform the requested task. Throttling can move very fast, although of course under full load the processor will be pegged at its maximum. In the still unresolved bug report ref'd in Heinz reply, there are some tools listed with which you can see the actual governor settings and detailed throttling results as it occurs. From that bug report there is suspicion that there may be a kernel bug but there is also the possibility that the problem is related to how the bios is handling ACPI; unfortunately bios bugs particularly re ACPI are not that uncommon so it wouldn't hurt the check for a bios update for your machine. If throttling is not working properly for you and there is no bios update, I would suggest following that bug thread (if it's in the kernel, it is serious) until a solution if found. If you can manage w/o throttling for a time, you can disable it altogether in the kernel by adding "cpufreq=no" to the kernel boot line - judging from a couple of the posts in the bug thread, you may need to do that to get above an incorrectly imposed limit. Re temperature, that is driven by core load not the other way around. As load is put on the processor, voltage is increased to raise clock which in turn generates the greater heat. I don't know Bubblemoon so I can't comment on its temperature reading method. It is conceivable that it is getting its temperature from ACPI (which if itself is a problem as hypothesized in the above bug report, I suppose could also affect the temp readings), from a cpu socket sensor, or from a thermal sensor embedded in the cpu itself; when the sensors package is being used for readings sometimes the algorithm needs to be adjusted (in the config file) for a particular machine. I use AMD processors, with which there have been hardware issues in the past with the internal thermal sensor as well as the sensor driver in the sensors package (since resolved). I don't know if there are any such issues with Intel. So in other words, temp variations could be due to the throttling issue, or not; could also be due to where/how Bubblemoon gets its readings. I would compare to what the sensors package reports. Re distribution of processes on the cores, my reply would be the same as Larry's. Note in your cpuinfo the number of cores is 2, not 4. Your i5 is essentially 2 dual-cores bolted together; that is a different architecture than a true quad. As already noted, the kernel will allocate load differently on the latter vs the former. Nothing above is a definitive answer, but hopefully helps a bit. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org