all voltages on zero but still running

[the-fallen]

Yeah, thats easy.

First, read your default values and remember them:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids

returns for example 12 10 8 6

The first Item should be the VID for your highest available ferquency (even if it may not be the highest value).

Now decrease that value by one.
now you have 11 10 8 6


Then write the whole string back (you must be root - sudo does not work; become root with "sudo -s")

Code: Select all

echo "11 10 8 6" > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids

Now manually set to the highest frequency, using gnomes CPU clock widget for example.
Another way may be to write the highest value from

Code: Select all

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

to

Code: Select all

/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

using the echo - command like above.

At last run read_msr --readmsr and check if you see your new value on the line "Current VID:".

[evil]

thank you, i will try as soon as possible.
few questions:

1 - do i have to do that separately for both cpus? i suppose yes

2 - once i am sure i set the VID correctly and i am at highest frequency, if the VID is too low, should it crash immediately or after a while?

3 - i have this:
evil@hell:~/Download/read_msr 0.2pre$ cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
74:43 10:37 8:30 6:23 134:19
i cannot understand the 134
is it really the lowest freq or is it just a weird translation from bits? (as 74 could be)

[the-fallen]

to 1: no, it should be enough to do that to one core

to 2: that depends on ... if it is very much too low then yes - it will crash immediately. If it is set "just a bit too low" it will crash when there is some load to the CPU. Maybe only the process that is currently running on the CPU crashes ... the result may vary.

to 3: it is both: really the lowest FID and also a weired translation of bits. Newer Core CPUs do have three (3) things: a FID, a VID and a DID. The latest is some kind of bus-frequency divider and is stored as a bit in the byte we once thought it is completly reserved for the FID. That is Wrong. We now know that the DID is bit 7, bit 6 is reserved, and bits 5:0 are the FID but PHC 0.3 is displaying the whole byte.

The next PHC version will take care of this.

[evil]

ok, thank you very much, i'll try.
but the second point is not so promising
an almost deterministic way to know the appropriate VID would be better
i think the script (which i attached) i used was doing that (exept that now it didn't work reliably anymore).
it required to start burnmmx on the second cpu to keep it 100% busy, then it started testing stressing the first cpu lowering VID, and when it crashed, it decides that 2 VIDs higher is the limit for that frequency.

i start having a little doubt about emifreq at the time of the tests. maybe it wasn't set at the highest freq.
i'll retry that first

[evil]

also, why do i have 5 freqs but from emifreq i can choose only 4?
in "fixed speed" list i have:
2668 (which corresponds to the same freq in "performance", i checked in file scaling_cur_freq)
2667
2133
1600
then in "powersaving" i have 800, not selectable from fixed speed.

retrying the script, the same happened.
1 - both cpu under stress 100%
2 - freq set on 2668
3 - bringing down 74:43 to 74:1 on cpu0 (temp over 60).
4 - it arrived at -1 and stopped the script and burnMMX on both cpus
5 - it reset on powersaving (as i usually keep it) and after about one minute it froze (cpu0 was still on 74:1)
i cannot explain why so late, and why the highest freq when i am supposed to be blocked with powersaving on the minimum

others with my problem:
http://ubuntuforums.org/showthread.php?p=4960606

[the-fallen]

I do not know emifreq. The problem with the different count of frequencies had been to ubuntu, too in earlier versions but this was gone soon.

You should not rely on a script when you do not exactly know what it is doing or how it is working internally. Maybe it struggles with those "strange" FIDs. I do not know.
If you want to be as sure as possible that everything is like you want it to be during a test you should stay with the low-level tools (like writing the frequency you like to run on to the sysfs-files).

I forgot to say that you need to use the "userspace" governor to manually set frequencies.

Look at
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

if this one is available, then echo it to

/sys/devices/system/cpu/cpu0/cpufreq/scaling_governors

[evil]

You should not rely on a script when you do not exactly know what it is doing or how it is working internally. Maybe it struggles with those "strange" FIDs. I do not know.
If you want to be as sure as possible that everything is like you want it to be during a test you should stay with the low-level tools (like writing the frequency you like to run on to the sysfs-files).

i agree with this, but i was looking after what the script was doing.
1 - i stressed the second cpu, which you said it wasn't necessary
2 - i was looking ath the vid while the script was running, and it was dropping it by 1, stressing, dropping another 1, stressing, and so on. i cat the file and yes, i saw them really dropping, like if i would have done manually

the userspace governor could be the problem though. i cannot say why, but i have the feeling that years ago when i tuned my old laptop's vids, i needed to do that to avoid strange fid jumps during the tests.

i'll let you know
(i am insisting a bit to defend the script because if we find where is the problem, i'd like to have an automatic vid tester/stresser instead of having to do it manually, people would appreciate it :p)

[the-fallen]

Yes, i prefer automatics, too. Just in your case where we do not know why it does not work I'd like to exclude every possible cause.

I hope we can find the reason why it is not working for you.

[evil]

probably i found out what happens with the script, even though i cannot understand why.

Read phc_default_vids:
> Success!

Read default VIDs.
> Success!
Reset position to 0.
Read available frequencies.
Available freqs: 2668000 2667000 2133000 1600000 800000 .
> Success!

Default VIDs: 43 37 30 23 19
Current VIDs: 43 37 30 23 19

Switch to 'userspace' scaling governor.
> Success!
Set frequency to 2668000.
> Success!
Run burnMMX.
PID: 4208

up to this point, all is ok, i checked the actual freq and it's really 2668.

-----
Start testing.
Do you want to continue? [Y/n/?] Yes

Default VIDs: 43 37 30 23 19
Current VIDs: 42 37 30 23 19
Testing VID: 42 (1372 mV)
..............................

it asks me to continue and waits fr input. during that, freq is still correct, but when i write yes, it starts the test and if i check the current freq, it switched to the lower one, 2667.
i couldn't find any freq change in the script, thus it must be some independent behavior, and i am clueless about such thing. (as much as understanding why should exist a 2668 and 2667...)

[evil]

i tried to confirm that, so i wrote a little easy script (attached).
i operate on both cpus, just to be sure.
well, i set userspace governor, then the freq 2668000 and print immediately to check it's in scaling_setspeed (or scaling_cur_freq). it is.
then i start changing the vids and let them stress for 15 seconds with burnMMX, but when i read scaling_setspeed it is at 2667000.

so, what is changing it back everytime?
edit: i just checked and apparently as soon as i echo the vids, the freq drops at 2667. no clue