powernow-k8 max speed sanity check

Hi all,

Following is a little patch to do a sanity check on the max speed and voltage values provided by the bios.

Some buggy bioses provide bad values if the cpu changes, for example, in my case the bios claims the max cpu speed is 1600MHz, while it's running at 1800MHz. (Cheapo Emachines m6805 you know...) This could also happen on machines where the cpu is upgraded.

These checks should be safe, as they only change things if the machine is already running at a higher speed than the bios claims.

Following is a little patch to do a sanity check on the max speed and voltage values provided by the bios.

Some buggy bioses provide bad values if the cpu changes, for example, in my case the bios claims the max cpu speed is 1600MHz, while it's running at 1800MHz. (Cheapo Emachines m6805 you know...) This could also happen on machines where the cpu is upgraded.

These checks should be safe, as they only change things if the machine is already running at a higher speed than the bios claims.

Hi!

Quoted 8 lines

Following is a little patch to do a sanity check on the max speed and voltage values provided by the bios.

Some buggy bioses provide bad values if the cpu changes, for example, in my case the bios claims the max cpu speed is 1600MHz, while it's running at 1800MHz. (Cheapo Emachines m6805 you know...) This could also happen on machines where the cpu is upgraded.

Quoted 3 lines

These checks should be safe, as they only change things if the machine is already running at a higher speed than the bios claims.

Someone should really bug them to fix their BIOS. (BTW does keyboard work ok for you?)

Going though ACPI solves this, and I have perhaps better patch to hardcode right values...

Quoted 2 lines

Someone should really bug them to fix their BIOS. (BTW does keyboard work ok for you?)

No problems with keyboard, and the cpufreq works fine with the patch, but not at all without the patch.

There are some ACPI related issues though, such as: via-rhine gets wrong irq with ACPI on, system hangs with yenta_socket loaded if I connect/disconnect the power cord... So for now, I don't use the PCMCIA.

Quoted 2 lines

Going though ACPI solves this, and I have perhaps better patch to hardcode right values...

Still, the max speed check should be safe. Maybe pass values as module options too? I would not trust on ACPI working right on this machine :)

Tony

Quoted 3 lines

Quoted 3 lines

Someone should really bug them to fix their BIOS. (BTW does keyboard work ok for you?)

Attached is my cpufreq patch. You may still prefer yours, but this one has correct tables derived from ACPI.

Quoted 4 lines

There are some ACPI related issues though, such as: via-rhine gets wrong irq with ACPI on, system hangs with yenta_socket loaded if I connect/disconnect the power cord... So for now, I don't use the PCMCIA.

They did something very stupid with io-ports at 0x4000. This should work around it. [Note, I probably have slightly different machine from you.]

Here's some comments after trying out your 2 patches.

First, the PCMCIA patch worked great, I can now plug/unplug power cord with yenta_socket loaded :) Maybe now I can _haul_ this laptop to a cafe and use the WLAN, hehe. In case anybody else needs them, I'll put the patches

The powernow-k8.c patch did not work, as my numpst is 8, not 3. So why not just ignore the numpst, as it is not used?

Maybe replace this

arch/i386/kernel/cpu/cpufreq/powernow-k8.c +5 -1

 		if (psb->numpst != 1) {
 			printk(KERN_ERR BFX "numpst must be 1\n");
-			return -ENODEV;
+			if (psb->numpst == 3) {
+				printk(KERN_INFO PFX "assuming arima notebug\n");
+				arima = 1;
+			} else
+				return -ENODEV;
 		}

With this instead:

I see a little problem with hardcoding the values:

arch/i386/kernel/cpu/cpufreq/powernow-k8.c +7 -0

+		if (arima) {
+			ppst[1].fid = 0x8;
+			ppst[1].vid = 0x6;
+#ifdef THREE
+			ppst[2].fid = 0xa;
+			ppst[2].vid = 0x2;
+#endif
 		}

This would fail if I upgraded my CPU, right?

What do you think about using module options maxfid and maxvid?

Well, I wanted some way to detect exactly this broken machine. You might want to simply put == 8 there.. but proper solution is DMI blacklist.

Quoted 2 lines

What do you think about using module options maxfid and maxvid?

Well, the original BIOS has not only maximum values wrong, but also 1600MHz wrong, as far as I can tell...

Something like /proc/frequencies file would be needed where you could

echo "0 0xa; 0x8 0x6; 0xa 0x2" > /proc/frequencies to override. You need to override all of them, not just top one.

Quoted 2 lines

Well, I wanted some way to detect exactly this broken machine. You might want to simply put == 8 there.. but proper solution is DMI blacklist.

Or just use the current running values for max speed. That will fail if the system boots at lower speeds on battery though. And the BIOS checks will fail on buggy BIOSes and when upgrading the CPU. So maybe use both checks?

Quoted 4 lines

Quoted 1 line

What do you think about using module options maxfid and maxvid?

Well, the original BIOS has not only maximum values wrong, but also 1600MHz wrong, as far as I can tell...

Outch! I did not know that...

Are the middle values needed? What if you only use the min and max fid/vid values, and always recalculate the stepping tables from those values?

Hi!

Quoted 3 lines

Quoted 2 lines

Well, I wanted some way to detect exactly this broken machine. You might want to simply put == 8 there.. but proper solution is DMI blacklist.

Quoted 3 lines

Or just use the current running values for max speed. That will fail if the system boots at lower speeds on battery though. And the BIOS checks will fail on buggy BIOSes and when upgrading the CPU. So maybe use both checks?

Well... for your own kernel hack it any way you want.

For public consumtion... I guess DMI blacklist and assume user did not exchange cpus... We could cross-check /proc/cpuinfo.

Quoted 7 lines

Quoted 4 lines

Quoted 1 line

What do you think about using module options maxfid and maxvid?

Well, the original BIOS has not only maximum values wrong, but also 1600MHz wrong, as far as I can tell...

Outch! I did not know that...

Quoted 3 lines

Are the middle values needed? What if you only use the min and max fid/vid values, and always recalculate the stepping tables from those values?

Well, 1600MHz operation is very nice, as it has significantly less power consumption but pretty much same performance. It also does not start CPU fan most of the time :-).

Quoted 4 lines

Quoted 3 lines

Are the middle values needed? What if you only use the min and max fid/vid values, and always recalculate the stepping tables from those values?

Quoted 3 lines

Well, 1600MHz operation is very nice, as it has significantly less power consumption but pretty much same performance. It also does not start CPU fan most of the time :-).

Yes, 1600MHz would be nice, I agree.

But I meant calculating all the valid values inbetween min and max without relying on getting those values from the BIOS.

I guess the code already does that to figure out how many steps are needed to change between min and max?

Quoted 3 lines

But I meant calculating all the valid values inbetween min and max without relying on getting those values from the BIOS.

I do not think values can be calculated by some simple formula. voltage/frequency relations may be quite complex..

Quoted 2 lines

I guess the code already does that to figure out how many steps are needed to change between min and max?

Well, but it steps voltage first, then frequency [going up] or frequency first, voltage then [going down]; middle values used by the transitions are not too good if you want to be power-efficient.