Linux ignores BIOS overclocks?

[Sonadow]

The computer I built for my mother 6 years ago utilizes an Athlon X2 7750 which is clocked at 2.7GHz on stock which downthrottles to 1.35GHz when Cool 'n' Quiet kicks in.

I tried going to the BIOS to overclock the processor to 3.3GHz, and, when booting Windows, both CPU-Z and Windows System Information show the new speed of 3.3GHz.

However, on Linux, running

cat /sys/device/system/cpu/cpu0/cpufreq/scaling_available_frequencies

still show 2700000 and 1350000 instead of 3300000.

Is there any way to make Linux use my overclocked frequencies?

[droste]

For the Intel i3, i5 and i7 the frequency that is reported by the kernel is not the real frequency of the cores. There's a small program which gives you the real frequency ( https://code.google.com/p/i7z/ ).

Maybe this program does the same for your AMD cpu:

http://www.amdzone.com/phpbb3/viewtopic.php?f=532&t=139102

https://code.google.com/p/turionpowercontrol/

[Sonadow]

No dice with TPC as well:

[root@localhost tpc-0.44-rc2-src]# ./TurionPowerControl  -l
TurionPowerControl 0.44-rc2 (export)
Turion Power States Optimization and Control - by blackshard

Main processor is Family 10h Processor
        Family: 0xf             Model: 0x2              Stepping: 0x3
        Extended Family: 0x10   Extended Model: 0x2
        Package Type: 0x1       BrandId: 0xcd3
Machine has 1 nodes
Processor has 2 cores
Processor has 5 p-states
Processor has 0 boost states

Power States table:
-- Node: 0 Core 0
core 0 pstate 0 (p0) - En:1 VID:20 FID:11 DID:0.00 Freq:2700 VCore:1.3000
core 0 pstate 1 (p1) - En:1 VID:20 FID:11 DID:1.00 Freq:1350 VCore:1.3000
core 0 pstate 2 (p2) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
core 0 pstate 3 (p3) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
core 0 pstate 4 (p4) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
-- Node: 0 Core 1
core 1 pstate 0 (p0) - En:1 VID:20 FID:11 DID:0.00 Freq:2700 VCore:1.3000
core 1 pstate 1 (p1) - En:1 VID:20 FID:11 DID:1.00 Freq:1350 VCore:1.3000
core 1 pstate 2 (p2) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
core 1 pstate 3 (p3) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500
core 1 pstate 4 (p4) - En:0 VID:0 FID:0 DID:0.00 Freq:1600 VCore:1.5500

 --- Node 0:
Processor Maximum PState: 1
Processor Startup PState: 1
[B]Processor Maximum Operating Frequency: 2700 MHz[/B]

Minimum allowed VID: 93 (0.3750V) - Maximum allowed VID 20 (1.3000V)
Processor AltVID: 40 (1.0500V)

Done.
[root@localhost tpc-0.44-rc2-src]#

[curaga]

Changing the main freq in the bios will not change the power tables - you would need to disable the power scaling, getting more heat/wattage.

[Sonadow]

Changing the main freq in the bios will not change the power tables - you would need to disable the power scaling, getting more heat/wattage.

That's how it works in Linux?

In Windows I didn't have to disable Cool n Quiet; the scaling frequencies are automatically adjusted to accommodate the overclocks.

[Forge]

I'm not sure if you're confused or if the programs you're using to check aren't telling you what you think they are.

With both Intel and AMD, overclocking does NOT create additional power management tables. On some systems, it changes the speed of the top speed entry, on others it does not, but either way, you're not looking in the right places.

Running something that loads the CPU and then grepping cpuinfo would be a better test, that is a real time number that reflects actual clockspeed, not just what powersaving modes are preset.

[droste]

/proc/cpuinfo is not reporting the correct frequency for my CPU (Intel i5)

/edit:
It shows a maximum of 2400MHz while the real value is 2891MHz maximum.
2400MHz is also the maximum in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies but that's simply not what the CPU really has as a maximum when running under full load.

[Luke]

Overclocking works, its just not reported.

My experience is that overclocking does work, and in AMD at least multiplier changes are reported. Base clock changes are NOT reported but are still present if frequency scaling is in use. Linux doesn't seem to override a changed BIOS clock, just ignore it and report the CPU to be using the stock base clock when in fact it is using another one. The "power meter" feature in AMD Bulldozer has a similar issue of not reporting changes in power use caused by overclocking, though you can easily see them in the temperature readings.

The proof of this is running a benchmark that loads at least one thread to near 100%, comparing a run with Cool 'n Quiet (frequency control) enabled but pinned to 100% in the userspace governor, vs running with Cool 'n Quiet disabled and the true frequency read. Same performance and same heat once stabilized at full load.