CPU Frequency Scaling does not work on my Fujitsu Siemens Lifebook E8310 as scaling_max_freq is always set to scaling_min_freq so no scaling is ever done. ( I have tried all available governors. # lsmod | grep cpu cpufreq_conservative 8072 1 cpufreq_ondemand 9612 0 acpi_cpufreq 10568 2 freq_table 5792 2 cpufreq_ondemand,acpi_cpufreq processor 32072 2 acpi_cpufreq,thermal ls /sys/devices/system/cpu/cpuX/cpufreq affected_cpus cpuinfo_cur_freq cpuinfo_min_freq scaling_available_governors scaling_driver scaling_max_freq cpuinfo_max_freq scaling_available_frequencies scaling_cur_freq scaling_governor scaling_min_freq cat scaling_available_frequencies 1801000 1800000 1200000 800000 cat scaling_governor ondemand cat scaling_min_freq 800000 cat scaling_max_freq 800000 Here is the (German) output of cpufreq-info: Bitte melden Sie Fehler an linux@brodo.de. analysiere CPU 0: Treiber: acpi-cpufreq Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0 1 Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 1.80 GHz mögliche Taktfrequenzen: 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz mögliche Regler: conservative, ondemand momentane Taktik: die Frequenz soll innerhalb 800 MHz und 800 MHz. liegen. Der Regler "userspace" kann frei entscheiden, welche Taktfrequenz innerhalb dieser Grenze verwendet wird. momentane Taktfrequenz ist 800 MHz (verifiziert durch Nachfrage bei der Hardware). analysiere CPU 1: Treiber: acpi-cpufreq Folgende CPUs können nur gleichzeitig ihre Frequenz variieren: 0 1 Hardwarebedingte Grenzen der Taktfrequenz: 800 MHz - 1.80 GHz mögliche Taktfrequenzen: 1.80 GHz, 1.80 GHz, 1.20 GHz, 800 MHz mögliche Regler: conservative, ondemand momentane Taktik: die Frequenz soll innerhalb 800 MHz und 800 MHz. liegen. Der Regler "userspace" kann frei entscheiden, welche Taktfrequenz innerhalb dieser Grenze verwendet wird. momentane Taktfrequenz ist 800 MHz (verifiziert durch Nachfrage bei der Hardware).
Created attachment 13305 [details] DSDT Table of the machine
Hi, Marcus, Please attach the full acpidump output. And please "echo 7 > /sys/module/cpufreq/parameters/debug" before loading the cpufreq driver and attach the dmesg output after the driver is loaded.
Created attachment 13351 [details] dmesg output after loading of acpi-cpufreq and cpufreq-ondemand
Created attachment 13352 [details] acpidump output
I have uploaded the required files. Please note that "echo 7 > /sys/module/cpufreq/parameters/debug" was impossible as the file does not exist on my machine. Marcus
dmesg output: >[ 14.569744] ACPI Error (tbinstal-0134): Table has invalid signature[ ], >must be SSDT, PSDT or OEMx [20070126] >[ 14.569753] ACPI Error (psparse-0551): Method parse/execution failed >[\_SB_._INI] (Node df840cf0), AE_BAD_SIGNATURE and >[ 125.344000] ACPI Error (psargs-0355): [\_SB_.PCI0.GFX0.LCD_.BLNF] >Namespace lookup failure, AE_NOT_FOUND >[ 125.344000] ACPI Error (psparse-0551): Method parse/execution failed >[\_GPE._L1C] (Node df84a678), AE_NOT_FOUND these are from your dmesg log, And this AML code is only executed only if \_SB.OSTP () is not less than 0x40. So please try to boot with osi="!Windows 2006", and attach the dmesg output. re: comment #5 please set CONFIG_CPU_FREQ_DEBUG and recompile your kernel. :)
Created attachment 13386 [details] dmesg output after loading of cpufreq and with acpi_osi="!Windows 2006" boot parameter With acpi_osi="!Windows 2006" scaling_max_freq is set correctly
That's good news. :) But I still don't see why the cpufreq problem is fix by acpi_osi string. It would be great if you can set CONFIG_CPU_FREQ_DEBUG and recompile the kernel. and then attach the dmesg output after loading the cpufreq driver both with and without the acpi_osi="!Window 2006".
Will you please upload the info using the following commands? a. acpidump --addr 0x3f6dfdd2 --length 0x238 -o cpuist0 b. acpidump --addr 0x3f6e02d2 --length 0x46e -o cpucst0 c. acpidump --addr 0x3f6e021A --length 0xb8 -o cpuist1 d. acpidump --addr 0x3f6e0740 --length 0x47 -o cpucst1 Thanks.
Sorry. These commands does not produce any output. Marcus
Created attachment 13485 [details] cpucst0
Created attachment 13486 [details] cpucst0
Created attachment 13487 [details] cpuist0
Created attachment 13488 [details] cpuist1
Okay. As you see I have noticed that output is piped to files ;) Marcus
This is an acpi_osi bug rather than cpu-freq bug. Linux/acpi always return true when evaluating _OSI method. IMO, this confuses the BIOS, because _OSI is designed for executing some platform specific AML code. So linux may run into troubles which are unexpected.
Created attachment 13521 [details] new dsdt with debug message The reason why acpi-cpufreq works is not clear yet. This is probably because that _PPC is always 0 without the acpi_osi string. Please override the dsdt with the one I attached. And send the dmesg output after acpi-cpufreq is loaded both with and without the acpi_osi="!Windows 2006".
_OSI is not intended to identify the underlying operating system. It is intended to identify what *interfaces* are supported by the underlying OS/ACPI. In the case of Linux/ACPICA, all of the Windows interfaces are supported, therefore TRUE is returned from _OSI for all Windows input strings.
Which still does not explain why it works with acpi_osi="!Windows 2006", or am I missing something. Best Regards Marcus PS: I am trying to force the new dsdt table asap.
Hi, Marcus Any update on this? Can you try the new dsdt and attach the dmesg output as I asked for in comment #17?
I don't think Linux/acpi can fix it as this is a bios problem. Close it and mark it as WILL_NOT_FIX. Please reopen it if you still have any questions.