# ACPI is funny (well sort of)

## kha

I have been playing around with quite a lot of different ACPI acces system (/proc/ACPI, /proc/cpufreq, /system/class) and here are the results : 

/proc/ACPI won't react to anything, I can echo all I want, nothing moves.

I have tried echo -n 1 > throttling and echo -n 1:0 > limits but the speed won't move by an inch, my commands are ignored. 

Conerning the other modes, then it is funny : I can't actually change the speed of my laptop but I can make the kernel think I did. The system clock will then go crazy and even the slightest touch of a key will make the character appears 5 times on the screen... 

Does somebody have these kinds of symptoms ? 

Kha

----------

## pilla

could you give more information about your notebook? Different brands and models have differents levels of ACPI support.

----------

## kha

My laptop is a Vaio PCG-GRZ660. The bios is a Phoenix (ARGH!) no way to switch to no pnp or to tweak anything (I can turn of the par port if I want though, and change the date too...). The processor is a P4 2.4 Ghz(not a mobile version though, so performance management is not present). 

Appart form this little issue everything seems to be working fine. 

In fact I already found quite a lot of way to save power, using a mix of HDPARM, spicctrl and iddle calls. Further more the screen is blanked after a while (even though I don't know how it is done, definitly not an ACPI event ).

So If i am not using my laptop my battery will last around 6 hours (against 2.5 when using it). 

Funny thing is that pluging and unpluging the AC adaptator will trigger a CPU event, but will leave it at full speed (processor CPU0 000000080 000000000)

But my point is not really to get help, (even though it would be great if someone could actually help me), but to know if this problem happens on other PC/LAPTOP. I am trying to write a prog to manage ACPI through a GUI, so that is why I would like to know. 

Kha

----------

## kha

OK, so it was really a bug :) there was a problem with the throttling writting system in /proc/acpi. It is now fixed as of 2.5.66 and perfectly working. 

Basically any writting operation aimed at throttling the CPU would fail, but the kernel would reccord it as OK and therefore adapt its speed accordingly, leading to the frenzy of the system. 

Now it is fixed and working. Il will test the 2.5.66 completly and try to write a gui to manage the ACPI. But I can make my processor go as slow as 300 Mghz (is a 2.4 Ghz)  without any problem. 

Now I can finally say that everything is working perfectly in my GRZ660. 

(And I won't have to recompile my dsdt, phew....)

Kha

----------

## kha

Ok, here are the results. I can definitly save quite a lot of power by throttling down the CPU, but not as much as I expected. It looks like the best way to save power is to decrease the brightness of my LCD screen and to use hdparm to set the sleeping mode fast.

Since the 2.5.66 kernel is quite unstable for me (USB not working one time out of 5, strange errors and unexpected crashes..) I will quit using it for now. So I am back to my good old 2.5.65 who never failed me except for the buggy throttle implementation. 

Kha

----------

## abclements

Without a doubt the screen draws THE most power on a laptop. With the screen turned off I can get about 2.5 hours of my laptop doing whatever processing task I need. with the screen on full, it lasts about 40 min.

----------

## magnet

I had the same problem with my /proc/acpi , I finally switched to sysfs  :Smile: 

if you still use the deprecated /proc/processor/ thing, there is a usefull tool called autospeedstep, that automagically switch your cpu speed, depending on the load.

I submitted a ebuild for it.

 :Very Happy: 

----------

## kha

 *Quote:*   

> I had the same problem with my /proc/acpi , I finally switched to sysfs
> 
> if you still use the deprecated /proc/processor/ thing, there is a usefull tool called autospeedstep

 

Sysfs won't work either with throttling, it will make the kernel thnik the processor is running slower while it is not, leading in a clock hysteria. In fact 2.5.66 is the first kernel where throttling is debuged. I hope this correction will be brought to 2.4.21, I definitly would love to have a real stable kernel for a change (even though I had no problem with my 2.5.65 so far). 

Concerning autospeedstep I know it and I do not like it. First because it will only work with a deprecated method on performance based processor (mostly mobile pentium, and some Athlon too I think). Second because it can be quite dangerous. This app makes no checks what so ever. First bad thing is that it won't check wether you already are in max speed or in low speed, if you are above 70% every 5 second it will try to speed up, and same goes for speed-down. 

Another thing I do not like is that it won't check wether or not the processor is in a "heat state", therefore trying to speed it up even if the processor slowed down to preserve itself (typically Mobile-P4). 

The mobile P4 2.4 Ghz uses both throttling and performance driving. basically the slowest mode possible when throttling is active (ie on a debugged kernel, 2.5.66 as of today) is around 300Mhz. Well 20% of 2.4Ghz is way more than 70% of 300Mhz. That could be quite fun to look at, but I do not want to test it on my CPU. Since the request AutoSpeedStep makes will triger the lowest possible speed rate on a debugged kernel using a Mobile-P4.... 

Oh by the way, even if I liked this app, I still could not use it, my processor is not a mobile, just a standard P4. 

I am currently trying to write an app that will perform quite a lot of tests before lauching itself and that would do more or less the same thing as autospeed step (+LCD brightness and HD management) but in a more secure and subtle way. 

Kha

----------

## magnet

hello,

I"m new to cpu throttling, I thinked that sysfs was the right was to do things.

what do you advice ? ( I have the clock weirdness problem) how should I change my cpu clock  

I own a laptop with a p4 and I'm running a kernel 2.5.65-mm3.  :Rolling Eyes: 

----------

## kha

Right now all kernel except 2.5.66 are buggy. Which means that tweaking the throttling in other kernel will result wether in nothing (good case) or time panic (bad case). 

The only good thing to do under new kernels (4.19+ or 2.5.54+) is echo -n in /proc/acpi. All other methods are wether deprecated or dangerous. 

Sysfs (/system/class/cpu/...) can report a success while a failure occured, leading to the clock madness, I tend not to use it for now, even though it will probably be the standard when everything is fixed. 

the best way to do things is to use ACPI limit (/proc/acpi/processor/CPUx/limit) it is the safe and official way to do things right (from the acpi standard point of view).  simply :  echo -n p:t > limit

with p=predefine performance point, and t=throttling mode. 

Globally echo -n 0:0 > limit will trigger the best speed available (t=0) when in performance mode (p=0). In the same way echo -n 1:7 > limit will trigger the worst speed (t=7) when in power-save mode (p=1). 

In PC like mine which does not have a powersave mode (no performance management) everything is considered to be in p=0 mode. 

By doing this you will actually update the user entry in limit, and if it is ok the actual state will conform. The good point is that if there is an alert (thermal for example) your entry will be ignored(that is in theory, actually almost nobody use this function).  

You can also echo the speed you want directly into throttling, that's not the proper way of doing thing, and if one day a manufacturer conforms to ACPI standard, you might actually override some processor securities. 

Once agian all of the above concerns throttling, not performance management and therefore works only with 2.5.66 kernel (and probably with a good set of ACPI patches which I am too lazy to investigate about right now). 

Hope that helped

Kha 

(au fait, je suis francais aussi)

----------

