PDA

View Full Version : CPU freq locking at 800MHz on 2GHz core 2 duo



jhsnyder
3rd August 2008, 10:40 PM
Quick summary:

2.2GHz laptop locked at 800MHz with 2.6.25(current) fedora kernel on 90W AC power from a cold start. I can't get it to run faster.

Looking for ways to get 2.2GHz out of my 2.2GHz dual processor.
_________________________________________

My 2.2GHz laptop seems to be locked at 800MHz. I'm not sure when this started, but it's definite with 2.6.25 kernels, running on AC (90W Dell adaptor) or AC (65W Dell adaptor (yep, I have both)) or battery.

OS fc8, uname -a:

Linux labrea 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 01:40:51 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
_____________________

Hardware:
Dell latitude d830, core 2 duo, processor T7500 2.2GHz, stepping 10, 4G mainstore
_____________________

This problem has been reported on archlinux and ubuntu fora. I can't find a reference on the fedora fora.

Here's (what I think is) the relevant part of /proc/cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 10
cpu MHz : 800.000
__________________________________________________ _____________

ditto "processor : 1"
__________________________________________________ _____________

cpufreq-info reports "max 2200, current 800"

I've tried:

sudo cpufreq-set -c [01] -f 2200

but afterwards cpufreq-info reports that both processors are running at 800MHz.

v-a-v on-demand: I ran a heavy-duty simulation that will suck up as many cpu cycles as the processor will give it. While this simulation is running, I check the cpu frequency. It is 800MHz.

Seems like this says that both processors are always running at 800MHz.

Nothing in /var/log/messages saying that the processors are switching from 2200 to 800MHz.

jhsnyder
3rd August 2008, 10:43 PM
BTW, this is a particularly insidious bug: unless you stumble across a message like this (as I did), you have no reason to assume that your 2.2GHz is running at anything but 2.2GHz.

Nokia
3rd August 2008, 10:48 PM
1. I don't think there should be any messages regarding speed changes

2. Can you do a parallel test with a fairly similar system not affected by the issue to see whether the progress is very different ? If not, the CPU might run at top speed without showing it. What does top command say ?

3. AFAIK, Archlinux is an Ubuntu-based distro, so there might be a common bug.

jhsnyder
3rd August 2008, 10:49 PM
Sorry, one more point.

Posts on various fora suggest that the problem is with the reporting of the processor frequency, not with the mechanics of processor frequency scaling.

I don't know of any empirical Gold Standard(tm) here which would tell me what frequency the processor is *really* running at.

However 800MHz is the minimum cpu reported cpu frequency, and every time I've run:

cat /proc/cpuinfo

the past couple of days, both processors have been reported at 800MHz, rain or shine, AC or battery, idle or heavy-duty simulation.

Which suggests that either the processors are stuck at 800MHz, or that the reporting system is *completely* broken.

jhsnyder
3rd August 2008, 10:55 PM
sorry, top with the default invocation in an xterm doesn't show CPU frequency.

Tell me exactly the CLI you want me to run, and I'll report the results.

re: "Can you do a parallel test with a fairly similar system not affected by the issue to see whether the progress is very different ? If not, the CPU might run at top speed without showing it."

Possible, but the only other core 2 duo system in the mix is my wife's Mac. I don't think she wants me to put linux on it. :-)

ppesci
3rd August 2008, 11:17 PM
Check the file:

/sys/devices/system/cpu/cpu0/scaling_available_frequencies

there are othe files in that directory tha can be informative too.

HTH

jhsnyder
3rd August 2008, 11:25 PM
uh, awkward pause.

I think you mean:

/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Ici:

2201000 2200000 1600000 1200000 800000

dejan.kitic
4th August 2008, 03:36 PM
I ve seen this on my Vostro laptop aswell...After suspend one core is locked at 800Mhz and the other one at 2Ghz...There was some discussion on forums about it, some claiming that s its not a bug(say on Core 2 Duo CPU) others claiming it to be a bug...One of the workarounds was to enable forced removal of modules from kernel (CONFIG_MODULE_FORCE_UNLOAD) and place rmmod -f acpi_freq then modprobe acpi_freq in
/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux .I ve tryed this one and it does work, after suspend both cores are acting normal...It s an ugly fix, but till it s fixed, only one i found that really works.

Correction
**As usual I messed up the module name .grrr... It s acpi_cpufreq not acpi_freq**

jhsnyder
4th August 2008, 04:38 PM
hunh, interesting.

I'll give it a try.. thanks!

Hlingler
4th August 2008, 11:34 PM
Service daemon irqbalance is installed and enabled by default, IIRC. Try configuring and (re)starting it?

V

ozjd
10th August 2008, 11:51 PM
I have a similar problem on my Dell 1520. Conky shows the first core doing all the work after suspend - resume.


I ve seen this on my Vostro laptop aswell...After suspend one core is locked at 800Mhz and the other one at 2Ghz...There was some discussion on forums about it, some claiming that s its not a bug(say on Core 2 Duo CPU) others claiming it to be a bug...One of the workarounds was to enable forced removal of modules from kernel (CONFIG_MODULE_FORCE_UNLOAD) and place rmmod -f acpi_freq then modprobe acpi_freq in
/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux .I ve tryed this one and it does work, after suspend both cores are acting normal...It s an ugly fix, but till it s fixed, only one i found that really works.

Correction
**As usual I messed up the module name .grrr... It s acpi_cpufreq not acpi_freq**

I tried this and it seems to make a small difference. The second core has some activity. (Compiz is using about 30% of cpu so that must be running on the first core). However if I reboot the load is much more even.

Any suggestions appreciated.

ozjd
11th August 2008, 03:24 AM
Update on previous post.
I rebooted and load between both cores is almost equal. Also noted that frequency is frequently changing between 1 and 2 GHz and in between. I have 2GHz T5750.
Also noted that memory is all ram, after suspend & resume it uses a few percent Swap, probably not related though.
System is fully updated.

dejan.kitic
11th August 2008, 12:52 PM
I never got the time to look deeper into this matter, i ve noticed it by accident, and for comparison of how cores are acting before and after suspend, I just used plain cat /proc/cpuinfo | grep "MHz" .Fix above gave me same behaviour as before suspend(on 2Ghz Intel Core2 Duo T7250).If I remeber well there were some usable info in dmesg after resume and what s happening with cores, perhaps it would be good place to peek and see what s up in more details.
Cheers,
dejan.kitic

ozjd
13th August 2008, 02:13 AM
If I remeber well there were some usable info in dmesg after resume and what s happening with cores, perhaps it would be good place to peek and see what s up in more details.


These lines are repeated several times in dmesg

CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching sched-domain:
domain 0: span 00000000,00000003
groups: 00000000,00000001 00000000,00000002
domain 1: span 00000000,00000003
groups: 00000000,00000003
CPU1 attaching sched-domain:
domain 0: span 00000000,00000003
groups: 00000000,00000002 00000000,00000001
domain 1: span 00000000,00000003
groups: 00000000,00000003

also this once, didn't seem to be any similar lines for cpu0 but I may have missed them.

CPU1 is up
Switched to high resolution mode on CPU 1

This was higher up


Enabling non-boot CPUs ...
CPU0 attaching NULL sched-domain.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 3990.06 BogoMIPS (lpj=1995031)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz stepping 0d

None of this means much to me but hoping someone else has some ideas.

ozjd
13th August 2008, 05:05 AM
There is a kernel update available today that claims to fix this problem. I will test when Livna catches up with the nVidia driver and report back.

fwelland
13th August 2008, 02:19 PM
I had a D820 2.0 core duo (T2500) - I have not noticed this problem recently (i.e. last 6 months) -- but haven't been looking either...

....but I had noticed a very similar problem with a D600 (Pentium M) -- only it would get stuck at 600MHZ -- and this only happened if the cold boot was from battery. If I boot with AC plugged in -- it was fine.


This is a snippet from my F5 howto that points to some links about the D600 problem I had.
http://mysite.verizon.net/vze2j8bn/D820-FC5.html#CPU_Scaling

essentially the hack was to do something like this:

echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
/etc/init.d/cpuspeed restart

I guess for core duo and core2dou you'd do this for each core and then restart the the cpu freq deamon .....

From what I recall, back in the day - on the D600, the problem was related to CPU speed reported on cold boot when on battery.


doubt any of this helps...but there it is...

dejan.kitic
13th August 2008, 03:43 PM
It was reported as upstream bug here : http://bugzilla.kernel.org/show_bug.cgi?id=10734 and resolved in latest acpica ( whatever that thingie is!? ).

ozjd
18th August 2008, 06:16 AM
The update for nvidia cards was finally released and I got a chance to test with the new kernel, 2.6.25.14-69.fc8.
It mentioned a bug for loading the first core to 80% after resume as one of the fixes. Unfortunately there is no change for me. The first core is still running at a constant 60 - 80% while the second core is barely functioning, even if I leave it for a few minutes.
On cold boot it runs properly, that is both cores are running at similar load.

psyzzle
12th September 2008, 01:15 PM
To get back to the original issue:

I've got a Fujitsu-Siemens laptop with a T7500 Core 2 Duo 2.2GHz processor as well, and it acts just as
described by the original poster. Both cores are running at 800 MHz according to /proc/cpuinfo (and
judging from the sluggishness, I would say that's most likely correct).



[psc@localhost ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
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 lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 4392.27
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 : 15
model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz
stepping : 11
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 10
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 lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips : 4388.78
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:




[root@localhost /sys/devices/system/cpu/cpu0/cpufreq]# for i in `ls` ; do echo $i ; cat $i ; echo "" ; done
affected_cpus
0 1

cpuinfo_cur_freq
800000

cpuinfo_max_freq
2201000

cpuinfo_min_freq
800000

scaling_available_frequencies
2201000 2200000 1600000 1200000 800000

scaling_available_governors
userspace performance

scaling_cur_freq
800000

scaling_driver
acpi-cpufreq

scaling_governor
userspace

scaling_max_freq
800000

scaling_min_freq
800000

scaling_setspeed
800000

psyzzle
12th September 2008, 03:03 PM
Ok. Ignore me. Apparently all it took was an updated kernel.

I ran a full system update and, apparently, a new kernel was downloaded.
As I didn't get any notification informing me that it might be a good idea to reboot,
I thought everything was fine.

I just rebooted for a different reason, and noticed an extra grub menu choice.
Aha!...

... and now everything works.