# [Solved] CPU frequency scaling - Centrino FS Amilo M3438G

## corrosif

Hi,

I am experiencing some trouble to change the frequency of my centrino.

Some months ago I can remember all was doing fine, but since some update, I (and a friend which has exactly the same computer and gentoo) can't make cpufreq recognize my CPU.

The strange thing is that this problem seems to have occurred independently from a kernel change.

I have a Fujitsu Siemens Amilo M3438G-75005 laptop with the following CPU:

```
 $ cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.86GHz

stepping        : 8

cpu MHz         : 800.037

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2

bogomips        : 1601.49

clflush size    : 64

```

```
$ x86info 

x86info v1.20.  Dave Jones 2001-2006

Feedback to <davej@redhat.com>.

Found 1 CPU

--------------------------------------------------------------------------

Family: 6 Model: 13 Stepping: 8 Type: 0 Brand: 6

CPU Model: Pentium M (Dothan) [C-0] Original OEM

Feature flags:

 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflsh ds acpi mmx fxsr sse sse2 ss tm pbe est tm2

Extended feature flags:

Cache info

 L1 Instruction cache: 32KB, 8-way associative. 64 byte line size.

 L1 Data cache: 32KB, 8-way associative. 64 byte line size.

 L2 unified cache: 2MB, sectored, 8-way associative. 64 byte line size.

TLB info

 Instruction TLB: 4K pages, 4-way associative, 128 entries.

 Instruction TLB: 4MB pages, fully associative, 2 entries

 Data TLB: 4K pages, 4-way associative, 128 entries.

 Data TLB: 4MB pages, 4-way associative, 8 entries

 64 byte prefetching.
```

The CPU is always working at 800MHz instead of 1.6GHz, even during compilation or other heavy computation.

For cpufreq, I have read that for my particular kind of centrino, I should use the module acpi_freq instead of speedstep_centrino.

For the moment, I have compiled both modules in my kernel, as you can see here:

```
#

# Power management options (ACPI, APM)

#

CONFIG_PM=y

# CONFIG_PM_LEGACY is not set

# CONFIG_PM_DEBUG is not set

CONFIG_PM_SYSFS_DEPRECATED=y

CONFIG_SOFTWARE_SUSPEND=y

CONFIG_PM_STD_PARTITION=""

#

# ACPI (Advanced Configuration and Power Interface) Support

#

CONFIG_ACPI=y

CONFIG_ACPI_SLEEP=y

CONFIG_ACPI_SLEEP_PROC_FS=y

# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set

CONFIG_ACPI_PROCFS=y

CONFIG_ACPI_AC=y

CONFIG_ACPI_BATTERY=y

CONFIG_ACPI_BUTTON=y

CONFIG_ACPI_FAN=y

# CONFIG_ACPI_DOCK is not set

CONFIG_ACPI_PROCESSOR=y

CONFIG_ACPI_THERMAL=y

# CONFIG_ACPI_ASUS is not set

# CONFIG_ACPI_TOSHIBA is not set

CONFIG_ACPI_BLACKLIST_YEAR=0

# CONFIG_ACPI_DEBUG is not set

CONFIG_ACPI_EC=y

CONFIG_ACPI_POWER=y

CONFIG_ACPI_SYSTEM=y

CONFIG_X86_PM_TIMER=y

# CONFIG_ACPI_CONTAINER is not set

# CONFIG_ACPI_SBS is not set

# CONFIG_APM is not set

#

# CPU Frequency scaling

#

CONFIG_CPU_FREQ=y

CONFIG_CPU_FREQ_TABLE=y

CONFIG_CPU_FREQ_DEBUG=y

CONFIG_CPU_FREQ_STAT=y

CONFIG_CPU_FREQ_STAT_DETAILS=y

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

CONFIG_CPU_FREQ_GOV_PERFORMANCE=y

CONFIG_CPU_FREQ_GOV_POWERSAVE=y

CONFIG_CPU_FREQ_GOV_USERSPACE=y

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#

# CPUFreq processor drivers

#

CONFIG_X86_ACPI_CPUFREQ=m

# CONFIG_X86_POWERNOW_K6 is not set

# CONFIG_X86_POWERNOW_K7 is not set

# CONFIG_X86_POWERNOW_K8 is not set

# CONFIG_X86_GX_SUSPMOD is not set

CONFIG_X86_SPEEDSTEP_CENTRINO=m

# CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI is not set

CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y

CONFIG_X86_SPEEDSTEP_ICH=m

# CONFIG_X86_SPEEDSTEP_SMI is not set

# CONFIG_X86_P4_CLOCKMOD is not set

# CONFIG_X86_CPUFREQ_NFORCE2 is not set

# CONFIG_X86_LONGRUN is not set

# CONFIG_X86_LONGHAUL is not set

# CONFIG_X86_E_POWERSAVER is not set

```

Here are the results if I try to include the module speedstep_centrino:

```
# modprobe speedstep_centrino

FATAL: Error inserting speedstep_centrino (/lib/modules/2.6.22-gentoo-r1/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): No such device

```

In dmesg, the following message appears (I have cpufreq.debug=7 in my kernel options):

```
cpufreq-core: trying to register driver centrino

cpufreq-core: adding CPU 0

speedstep-centrino: found unsupported CPU with Enhanced SpeedStep: send /proc/cpuinfo to cpufreq@lists.linux.org.uk

cpufreq-core: initialization failed

cpufreq-core: no CPU initialized for driver centrino

cpufreq-core: unregistering CPU 0

```

Which is what I expected, as some other forums are telling I should use acpi_cpufreq for my particular kind of centrino.

So I tried the following:

```
# modprobe acpi_cpufreq

FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.22-gentoo-r1/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

```

This time, the following message appears in dmesg:

```
acpi-cpufreq: acpi_cpufreq_init

acpi-cpufreq: acpi_cpufreq_early_init

cpufreq-core: trying to register driver acpi-cpufreq

cpufreq-core: adding CPU 0

acpi-cpufreq: acpi_cpufreq_cpu_init

cpufreq-core: initialization failed

cpufreq-core: no CPU initialized for driver acpi-cpufreq

cpufreq-core: unregistering CPU 0

```

If I look into /sys, I can't find anything:

```
# cd /sys/devices/system/cpu/cpu0/

amilo cpu0 # ls -al

total 0

drwxr-xr-x 2 root root 0 jui 29 11:30 .

drwxr-xr-x 3 root root 0 jui 29 11:30 ..

```

As a thought, I was wondering if I had a broken DSDT, so I tried to disassemble it and then reassemble, and see if there were any error:

```
# cat /proc/acpi/dsdt > dsdt.dat

# iasl -d dsdt.dat

Intel ACPI Component Architecture

AML Disassembler version 20060912 [Jul 29 2007]

Copyright (C) 2000 - 2006 Intel Corporation

Supports ACPI Specification Revision 3.0a

Loading Acpi table from file dsdt.dat

Acpi table [DSDT] successfully installed and loaded

Pass 1 parse of [DSDT]

Pass 2 parse of [DSDT]

Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

...................................

Parsing completed

Disassembly completed, written to "dsdt.dsl"

# iasl -tc dsdt.dsl

Intel ACPI Component Architecture

ASL Optimizing Compiler version 20060912 [Jul 29 2007]

Copyright (C) 2000 - 2006 Intel Corporation

Supports ACPI Specification Revision 3.0a

dsdt.dsl  2018:                             Store (0x1F, DBG8)

Warning  1098 -              Statement is unreachable ^ 

dsdt.dsl  2023:                             Store (0x0F, DBG8)

Warning  1098 -              Statement is unreachable ^ 

dsdt.dsl  4015:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4029:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4044:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4059:             Acquire (MUTE, 0x0FFF)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4073:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4088:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

dsdt.dsl  4103:             Acquire (MUTE, 0x03E8)

Warning  1103 -                                 ^ Possible operator timeout is ignored

ASL Input:  dsdt.dsl - 4407 lines, 146160 bytes, 1785 keywords

AML Output: dsdt.aml - 16436 bytes 565 named objects 1220 executable opcodes

Compilation complete. 0 Errors, 9 Warnings, 0 Remarks, 637 Optimizations

```

As you can see, there are only some warnings, and no error... so I don't think the DSDT should be the problem.

And I can still remember the CPU frequency change was possible some months ago, so there could be a way to work with it.

Do you have any hint how to solve this problem?

It is so sad to work in Gentoo with only the half of my processor frequency.

Thanks!

----------

## Sachankara

Have you enabled HPET? Without it, CPU scaling will not work (at least not for me).

----------

## corrosif

Yes, HPET is already activated in my kernel, in the section "Processor type and features":

```
CONFIG_HPET_TIMER=y

```

----------

## dafi

So maybe , simply, it is just some kernel bugs. If everything worked fine few months ago, try to downgrade your kernel sources .

----------

## corrosif

I already tried on both kernel 2.6.19 and 2.6.22-r1.

The strange thing is that phenomenon appeared independently from a kernel update.

I wonder if such thing could be related to something else, like HAL, dbus...

Is there a way to make cpufreq debugging more verbose than what I have made?

"cpufreq-core: initialization failed" is not very explicit...

----------

## dafi

Did you enable in CPU Frequency scaling 

```
Enable CPUFreq Debugging
```

 ??

----------

## corrosif

Well as mentioned upper, I have the following option in my kernel:

```
CONFIG_CPU_FREQ_DEBUG=y 

```

and I have booted with the parameter cpufreq.debug=7 in my kernel options (inside grub.conf).

So cpufreq debug should be active.

----------

## bastibasti

Can you try to at least

```

CONFIG_X86_SPEEDSTEP_CENTRINO=y

```

I have not the same cpu, but simmilar problems. I have simplay (testing) enabled all intel cpu-types in kernel and it works fine.

----------

## adsmith

Have you tried speedstep_smi or speedstep_ich?  On one of my laptops, the CPU is reported improperly, and one of these works.

----------

## corrosif

Still no luck...

When I try to insert the module speedstep_smi:

```
# modprobe speedstep_smi

FATAL: Error inserting speedstep_smi (/lib/modules/2.6.22-gentoo-r1/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-smi.ko): No such device

```

In dmesg, I get the following:

```
speedstep-lib: x86: 6, model: d

speedstep-smi: No supported Intel CPU detected.

```

When I try with speedstep_ich:

```
# modprobe speedstep_ich

FATAL: Error inserting speedstep_ich (/lib/modules/2.6.22-gentoo-r1/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-ich.ko): No such device
```

In dmesg, I get the following:

```
speedstep-lib: x86: 6, model: d

speedstep-ich: Intel(R) SpeedStep(TM) capable processor not found
```

----------

## DLMK

I have had exactly the same problem with my Centrino (Dothan Core)

While googling around the net I found the following page:

http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU

I followed the instructions there and patched my kernel (gentoo-sources-2.6.22-r1 and gentoo-sources-2.6.22-r2 tested) with the phc-patch. The patch for Kernel 2.6.22 isn't released atm, but one can browse the repository and pick up the necessary files from there...

You will need:

```

- Kconfig

- Makefile

- speedstep-centrino.c

- acpi-cpufreq.c

```

and place them into /usr/src/your2.6.22kernel/arch/i386/kernel/cpu/cpufreq/

Then just follow the buildinstructions from that page

After a reboot with the new kernel a cat /proc/cpuinfo gave me:

```

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.70GHz

stepping        : 6

cpu MHz         : 600.000

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2

bogomips        : 1200.79

clflush size    : 64

```

So if you don't edit the corevoltage in speedstep-centrino it will use the normal vcores for your cpu and everything should be fine

----------

## corrosif

Many thanks, everything is back to normal now, even automatic cpu frequency scaling works.

With full speed, I now get:

```
$ cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 13

model name      : Intel(R) Pentium(R) M processor 1.86GHz

stepping        : 8

cpu MHz         : 1862.000

cache size      : 2048 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 2

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2

bogomips        : 3739.55

clflush size    : 64

```

Here are the exact steps I followed, in case anyone might be interested:

```
cd ~

mkdir linux-phc

cd linux-phc

svn co https://www.dedigentoo.org/ro-svn/linux-phc/trunk/src/kernels/vanilla-latest/linux.phc/arch/i386/kernel/cpu/cpufreq .

cp Kconfig /usr/src/linux-2.6.22-gentoo-r2/arch/i386/kernel/cpu/cpufreq

cp Makefile /usr/src/linux-2.6.22-gentoo-r2/arch/i386/kernel/cpu/cpufreq

cp speedstep-centrino.c /usr/src/linux-2.6.22-gentoo-r2/arch/i386/kernel/cpu/cpufreq

cp acpi-cpufreq.c /usr/src/linux-2.6.22-gentoo-r2/arch/i386/kernel/cpu/cpufreq

```

Rebuild the kernel with the following options:

```

-> Power management options (ACPI, APM)

  -> CPU Frequency scaling

    -> CPU Frequency scaling (CPU_FREQ [y])

[*] CPU Frequency scaling

[*]   Enable CPUfreq debugging

<*>   CPU frequency translation statistics

[*]     CPU frequency translation statistics details

      Default CPUFreq governor (performance)  --->

---   'performance' governor

<*>   'powersave' governor

<*>   'userspace' governor for userspace frequency scaling

<*>   'ondemand' cpufreq policy governor

<*>   'conservative' cpufreq governor

---   CPUFreq processor drivers

<*>   ACPI Processor P-States driver

< >   AMD Mobile K6-2/K6-3 PowerNow!

< >   AMD Mobile Athlon/Duron PowerNow!

< >   AMD Opteron/Athlon64 PowerNow!

< >   Cyrix MediaGX/NatSemi Geode Suspend Modulation

<*>   Intel Enhanced SpeedStep

[*]     Userspace control of CPU frequency/voltage table

[ ]     Use ACPI tables to decode valid frequency/voltage pairs

[*]     Built-in tables

[*]       Built-in tables for Banias CPUs

[*]       Built-in tables for Dothan CPUs

[*]       Built-in tables for Sonoma CPUs

< >   Intel Speedstep on ICH-M chipsets (ioport interface)

< >   Intel SpeedStep on 440BX/ZX/MX chipsets (SMI interface)

< >   Intel Pentium 4 clock modulation

< >   nVidia nForce2 FSB changing

< >   Transmeta LongRun

< >   VIA Cyrix III Longhaul

---   shared options

[ ]   /proc/acpi/processor/../performance interface (deprecated)

```

(It is important not to forget the "ACPI Processor P-States driver")

Don't forget to update your grub/lilo configuration  :Smile: 

Reboot.

----------

## corrosif

Well, as the linux-phc solution is rather hackish... let's instead fix the DSDT itself!

The following works nicely even with latest kernel (2.6.26).

First, to start from clean bases, I suggest to install latest BIOS v1.10C (even if DSDT errors are the same for all versions!)... download file:

FSC_BIOSWindowsFlashEXEAMILOM3438GM4438G_110C_1004536.EXE

from:

http://support.fujitsu-siemens.com/com/support/downloads.html

(choose: BIOS Windows Flash (EXE) - AMILO M3438G / M4438G)

After flashing under Windows, go back to linux and extract DSDT table:

```
# cat /proc/acpi/dsdt > dsdt.dat

# iasl -d dsdt.dat
```

Edit dsdt.dsl file, and modify it the following way.

At line 2029, replace:

```
If (Local0)

{

    Return (0x1F)

    Store (0x1F, DBG8)

}

Else

{

    Return (0x0F)

    Store (0x0F, DBG8)

}
```

by:

```
If (Local0)

{

    Store (0x1F, DBG8)

    Return (0x1F)

}

Else

{

    Store (0x0F, DBG8)

    Return (0x0F)

}
```

At line 4029, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

At line 4043, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

At line 4058, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

At line 4073, replace:

```
Acquire (MUTE, 0x0FFF)
```

by

```
Acquire (MUTE, 0xFFFF)
```

At line 4087, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

At line 4102, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

At line 4117, replace:

```
Acquire (MUTE, 0x03E8)
```

by:

```
Acquire (MUTE, 0xFFFF)
```

Save file, and assemble it:

```
# iasl -tc dsdt.dsl
```

This time, there shall be no error nor warning.

```
cp dsdt.hex /usr/src/linux/include/acpi/dsdt_table.h
```

In kernel configuration, make sure you have the following unchecked:

```
Device Drivers --->

  Generic Driver Options --->

    [ ] Select only drivers that don't need compile-time external firmware

    [ ] Prevent firmware from being built
```

... and activate custom DSDT table support, by specifying the path to the dsdt_table.h file:

```
Power management options (ACPI, APM) --->

  ACPI (Advanced Configuration and Power Interface) Support --->

    [*] Include Custom DSDT

    (/usr/src/linux/include/acpi/dsdt_table.h) Custom DSDT Table file to include
```

CPU frequency scaling should now work nicely!

It also solves the problems with the volume button.

----------

