Problem :
Currently working on an issue and am looking for some guidance.
Our current setup is a dual core (i5-4300U) Advantech box running Ubuntu 14.04.
I am seeing these rare occasions where the CPU cores go from ~2GHz and get immediately underclocked to 250 MHz and it stays there until I reboot the system.
Note that the cpuinfo_min_freq is set to 800MHz and that the power scaling governor is set to power savings.
My initial reaction was that it was temperature related but looking at the temperature, the cores are normally around the mid 30s C and were at the high 30s when this latest incident occurred. Which does not seem like its too drastic of a jump or out of a healthy. See attached screen shots.
A few questions:
- Are there other factors outside of temperature that would cause the CPU frequency to be reduced like it is?
- Does it seem odd that it would be reduced below the min setting? What would cause this?
-
Any other general insights or things I should look into on this setup?
>>:~$ uname -a Linux host 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:06:37 UTC 2016 i686 i686 i686 GNU/Linux >>:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 69 model name : Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz stepping : 1 microcode : 0x16 cpu MHz : 1899.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 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 nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts bugs : bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 69 model name : Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz stepping : 1 microcode : 0x16 cpu MHz : 1901.953 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 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 nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts bugs : bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 69 model name : Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz stepping : 1 microcode : 0x16 cpu MHz : 1899.902 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 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 nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts bugs : bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 69 model name : Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz stepping : 1 microcode : 0x16 cpu MHz : 1902.246 cache size : 3072 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 apicid : 3 initial apicid : 3 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 13 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 nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt dtherm ida arat pln pts bugs : bogomips : 4988.23 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
Solution :
Is that speed supported?
Is 250MHz even a supported frequency? Looking here should show what’s available (250MHz would appear as 250000):
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
Are you seeing accurate speeds?
Ignoring what the set minimum should be, if 250MHz isn’t even supported then I’m guessing either the frequency monitor program you’re using is having problems, or the frequency daemon (kernel?) is.
What are you using to monitor the cpu frequency? cpufreq-info (from cpufrequtils), or directly reading the “cpu MHz” line from /proc/cpuinfo or
cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
or depending on your driver (in the scaling_driver file)
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
I’d definitely check all of them when the issue comes up.
It’s also worth checking the general performance when the problem happens too. Comparing a benchmark to it’s speed when the CPU is acting normally could help confirm if it’s really slowing down, or just “saying” it’s slow. Good benchmarks include:
openssl speed md5(thanks David Schwartz)cryptsetup benchmark- One of the benchmarks from
hardinfo(Ubuntu’s help wiki, Debian, GitHub)- archlinux’s wiki has a nice page on Benchmarking in general
-
Just watching
dd‘s GB/s speed on virtual “files” might be sufficient (though it varies ~0.5GB/s with each run in my tests just now):if=/dev/zero of=/dev/null bs=1M count=10000 10000+0 records in 10000+0 records out 10485760000 bytes (10 GB, 9.8 GiB) copied, 1.69302 s, 6.2 GB/s
If it appears to be a confirmed problem with all sources, I’d try a different kernel.