Bug 9245
Summary: | need acpi_osi="!Windows 2006" to make acpi-cpufreq work on Lifebook E8310 | ||
---|---|---|---|
Product: | ACPI | Reporter: | Marcus Moeller (mm) |
Component: | Other | Assignee: | Zhang Rui (rui.zhang) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | all | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
DSDT Table of the machine
dmesg output after loading of acpi-cpufreq and cpufreq-ondemand acpidump output dmesg output after loading of cpufreq and with acpi_osi="!Windows 2006" boot parameter cpucst0 cpucst0 cpuist0 cpuist1 new dsdt with debug message |
Description
Marcus Moeller
2007-10-28 13:22:14 UTC
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. |