# [SOLVED] CPU frequency scaling on Pentium M (Dothan)

## Marcih

Hi all,

I've followed the power management guides on the Gentoo Wiki (https://wiki.gentoo.org/wiki/Power_management , https://wiki.gentoo.org/wiki/Power_management/Guide) to try and reduce the power usage on my Acer TravelMate 2414WLMi laptop originally fitted with an Intel Celeron M 380 @ 1.6 GHz, recently upgraded to a Pentium M 770 @ 2.13 GHz (it was listed Field Replaceable Unit list in the service manual, works just fine). Problems arose when I tried to use laptop-mode-tools. When (re)starting the service, my laptop (kernel?) would freeze and wouldn't respond to any keyboard inputs, the known method of "hold down the power button" needed to be used to shut down.  :Wink:  The same thing would happen a couple of times at boot after fsck or at "Caching service dependencies..." and at shutdown at the "Remounting/read only" point. At first I thought it was an issue with laptop-mode-tools spinning down of the HDD but upon further inspection it seems to be that the culprit was the CPU frequency scaling because it doesn't seem to work at all! I'm using acpi-cpufreq instead of speedstep-centrino as the CPU frequency scaling driver as per the Wiki's and kernel configuration tool's recommendation and I've compiled the kernel with ACPI_PROCESSOR [=y]. Here's what I found:

 The system always boots with the frequency listed in /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq regardless of whether the governor is set as "performance", "userspace", "ondemand" or "conservative" as the default in the kernel configuration (I assume it would boot with the scaling_min_freq value if it was possible to have "powersave" as default).

 The CPU completely ignores the dynamic governor, frequency stays static when "ondemand" or "conservative" is set, but setting to "powersave" or "performance" works as intended (it sets the frequency to the value listed in /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq or /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq respectively) although all of the governors (conservative, ondemand, powersave, userspace and performance) are listed in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

 The system freezes/locks up (same way as it did at scenarios described above) when the governor is changed AFTER it has been set to either ondemand or conservative. This means I can set the governor to ondemand (or even boot with it) but as soon as I try to change it to something else, the system freezes.

 When the speedstep-centrino driver is used, the /sys/devices/system/cpu/cpu0/cpufreq folder doesn't exist.

The chip is supposed to support Enhanced SpeedStep according to Intel (https://ark.intel.com/products/27597/Intel-Pentium-M-Processor-770-2M-Cache-2_13-GHz-533-MHz-FSB) whose functionality is supposed to be supported by the acpi-cpufreq driver, so I've kind of run out of ideas.

I can provide any additional info needed like dmesg outputs or my kernel's .config, feel free to ask.

Any help is appreciated  :Smile: Last edited by Marcih on Tue May 05, 2020 6:21 pm; edited 3 times in total

----------

## roarinelk

acpi-cpufreq should be the correct driver for the dothan p-ms.  Maybe your bios doesn't fully recognize the 770 model, because

it's responsible for providing the frequency state tables for acpi-cpufreq.  The behavior you describe (only min/max freq) would

support that theory (or it really only has 2 states  :o )

----------

## Marcih

 *roarinelk wrote:*   

> Maybe your bios doesn't fully recognize the 770 model

 

Hmm, I wouldn't say that's the problem. I don't know what constitutes as not fully recognized but I assume having the processor change from "Intel (R) Celeron (R) M processor   1.6Ghz" to "Intel (R) Pentium (R) M processor   2.13GHz" in the "CPU type" line in the BIOS is as recognized as it can get...  :Confused:  As I said in the OP, the 770 is listed in the FRU list in the service manual (here it is for reference: https://archive.org/details/service-manual-acer-travelmate-2410 )

 *roarinelk wrote:*   

> The behavior you describe (only min/max freq) would support that theory (or it really only has 2 states   )

 

I should probably clarify that setting the governor to userspace and setting the frequency manually with

```
$echo xyz > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
```

does indeed set the speed to a desired value (with xyz being a number in Hz).

Another thing that makes me doubt it's the BIOS' fault:

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

2133000 1867000 1333000 1067000 800000
```

So it seems like the BIOS is reporting what frequencies should be available for the governor to set automatically. And even if it was only capable of 2 states, the ondemand governor should still function since all it does is switch between scaling_max_freq and scaling_min_freq depending on the load, right?

----------

## Marcih

*sigh* So I suppose it is the BIOS' fault. I just tried replacing the Pentium with the Celeron the laptop came with and this time it even refused to load the cpufreq driver! The behaviour was very similar to what was discussed in this thread: https://forums.gentoo.org/viewtopic-t-572989.html

 *corrosif wrote:*   

> Here are the results if I try to include the module speedstep_centrino:
> 
> ```
> # modprobe speedstep_centrino
> 
> ...

 

In the same thread, something called "Differentiated System Description Table" is discussed and OP seems to have found a solution by fixing it. I tried to follow the ArchWiki article on decompiling and recompiling to check for errors and the result was:

```
Compilation complete. 11 Errors, 6 Warnings, 12 Remarks, 456 Optimizations
```

 :Shocked:   :Exclamation:  Ouch. I'm honestly out of ideas here. I have no idea how this works or where to even start. I can of course post the decompiled dsdt.dsl if somebody would like to give me a hand/walk me though it/fix it for me.  :Laughing: 

----------

## Jaglover

There are distros designed to run on as wide range hardware as possible. For instance Systemrescue. Have you tried to boot one of those, did frequency scaling work?

----------

## Marcih

 *Jaglover wrote:*   

> There are distros designed to run on as wide range hardware as possible. For instance Systemrescue. Have you tried to boot one of those, did frequency scaling work?

 

Thanks for the tip, but as I suspected after finding out what I wrote in the previous post, I got the exact same result as on my Gentoo install.

What do I do now? I'm nowhere near experienced (or brave) enough to try to patch the DSDT myself and the database over at http://acpi.sourceforge.net/dsdt/ seems to no longer be functional...  :Sad: 

Also, I love your .sig  :Wink: 

----------

## Marcih

SOLVED!

After looking around a bit on the Web, I realised that loading your own DSDTs was a thing of the past (hence all the ancient threads and the dysfunctional database) and that the Linux ACPI project wants to make sure you needn't do that:

 *Linux ACPI FAQ wrote:*   

> In the early days of Linux ACPI, DSDT modifications were common to work around both BIOS bugs and Linux bugs. However, the stated goal of the Linux ACPI project today is that Linux should run on unmodified firmware.

 

After I had unmasked all the gentoo-sources in x86 testing, configured and compiled the 4.15.5 kernel, booted up and tried to change the governor... It worked as intended...  :Rolling Eyes: 

I do apologise for posting about an issue that was fixed long ago.  :Laughing: 

----------

## bunder

my understanding is that the kernel acpi devs don't want people doing the old dsdt fix anymore.  if you think you need one, you should probably file a bug with the linux acpi folks.   :Confused: 

----------

