Bug 10383

Summary: CPU FREQ policy value scaling_max_freq gets stuck at 800MHz on core2duo
Product: Power Management Reporter: Ralf Kaestner (ralf.kaestner)
Component: cpufreqAssignee: Thomas Renninger (trenn)
Status: CLOSED DUPLICATE    
Severity: normal CC: alex, lenb, ralf.kaestner
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.24 Subsystem:
Regression: No Bisected commit-id:
Attachments: cpufreq-info when the problem is visible
cpufreq-info called multiple times showing the down-scaling of the policy
dmesg without debug data
dmesg output with cpufreq-debug=7
dump of the related sysfs parts
content of /proc/acpi/dsdt
output of acpidump (hex data)
the suspicious acpi table error extracted from dmesg/messages
content of /proc/cpuinfo

Description Ralf Kaestner 2008-04-02 10:41:32 UTC
Latest working kernel version: none found
Earliest failing kernel version:
Distribution: tested with ubuntu hardy and gentoo including vanilla kernel testing under gentoo
Hardware Environment: core2duo T7700 (2.4GHz), FSC Lifebook E8410
Software Environment: currently I run ubuntu 8.04

I would like to get some further input from kernel-dev how to proceed, please let me know if the following issue is most likely (or even not) a linux kernel issue and what steps I may take to solve it even if it may not be a kernel problem. I am open to talk to my Laptop Vendor or linux-distribution-support if one may give me some further details that would fingerpoint other parties than the kernel itself. I decided to open a bug with kernel-dev directly since I tested multiple distributions as well as vanilla-kernel without any changes to the issue itself. So I don't think its distribution related.



Summary
---------------------
CPU: core2duo T7700 (2.4GHz) - see cpuinfo.txt
CPU FREQ policy value scaling_max_freq gets stuck at 800MHz.
Notebook: FSC Lifebook E8410 (for further details on the hardware refer to: http://www.kuarepoti-dju.net/lifebook/)


Problem Description
---------------------
The CPU frequency scaling does not work as expected. The policy gets scaled down to a max frequency of 800MHz and then it does never scale up anymore. Short after boot, scaling seems to be still working (at least downwards). /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table shows multiple transitions, in my opinion too many (see sysfs.txt and look at the trans_table). After init5 is reached and I am able to log in I can use cpufreq-info immediately to check the situation and recognized that the policy still allows switching between 800 MHz and 1.60 GHz, but then the scaling_max_freq goes down within seconds to 800 MHz and gets stuck there, see cpufreq-info_steppingdown_afterboot.txt


Further Details
---------------------
- tried any governor
- cpufreq-set -s / -u does not change anything
- no cpufreq daemon or anything like that is running that would modify the scaling_max_freq, issue also exists in init-1
- not a temperature issue, CPU thermal sensor is at 27 degrees celsius
- inspected the acpi stuff and there seems to be a dsdt issue (refer suspicious_acpi_errors.txt as well as dmesg.txt) - I dunno if this is related
- I reloaded bios defaults without any change and tested any possible bios setting
- I compiled a custom ubuntu kernel with cpufreq-debug enabled, see dmesg.cpufreqdebug.txt - it looks like the table with states P0-P5 is detected correctly but then it transitons down, I have not too much experience with this stuff, so I am not sure if this is done by the kernel or by the Bios


Looks like a Bios issue, why not reporting it to Laptop-Vendor
---------------------
- Windows works like a charm in regards to cpu frequency scaling, so there must be at least a workaround
- If you want me to escalate to Laptop-Vendor instead, just let me know some details, I would need "ammo"
- The Bios has different possible settings:

[0] + advanced
[1] + + CPU Features
[2] + + + Speedstep (R) Technology: Enabled / Disabled
[3] + + + + On Battery: Maximum Performance / Battery Optimized / Automatic
[4] + + + + On AC: Maximum Performance / Battery Optimized / Automatic
[5] + + Miscellaneous Configurations
[6] + + + Hardware Power Management: Enabled / Disabled

- setting [2] to disabled keeps the CPU at 2.4 GHz all time, acpi-cpufreq does not even load anymore (this is my current workaround)
- any modifications (tried all combinations) in [3] [4] or [6] do not change the behaviour
- I'm running the latest Bios, already applied different updates without any change (the releasenotes do not state any issuesrelated to cpufreq - see: http://support.fujitsu-siemens.de/Download/ShowDescription.asp?SoftwareGUID=189E5137-473F-483F-ACAD-C4F161DA9768&OSID=665F4A20-6E31-43C3-82C2-D98CE773007C&Status=True&Component=Flash%20Bios%20for%20LIFEBOOK%20E8410%20(Mainstream)
- Bios also has some "silent fan" setting which I tried in both options (silent/normal) without any change

Distribution Details
---------------------
- tried Gentoo, latest devel kernel
- currently running ubuntu hardy latest beta
- latest vanilla kernel 2.6.24 shows the same behavior

References with same or similar signatures that I did read (without finding any working solution btw.)
---------------------
http://ubuntuforums.org/showthread.php?t=700865
http://suseforums.net/index.php?showtopic=41562
http://bbs.archlinux.org/viewtopic.php?pid=318802
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/88899
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/132271
http://bugzilla.kernel.org/show_bug.cgi?id=9353
http://bugzilla.kernel.org/show_bug.cgi?id=8245
http://bugzilla.kernel.org/show_bug.cgi?id=8228

Reproduction
---------------------

One would require the same Notebook to reproduce, so this makes no sense by now.
I'm hoping to get any feedback without the requirement to get this reproduced.
Comment 1 Ralf Kaestner 2008-04-02 10:42:40 UTC
Created attachment 15572 [details]
cpufreq-info when the problem is visible
Comment 2 Ralf Kaestner 2008-04-02 10:43:22 UTC
Created attachment 15573 [details]
cpufreq-info called multiple times showing the down-scaling of the policy
Comment 3 Ralf Kaestner 2008-04-02 10:44:00 UTC
Created attachment 15574 [details]
dmesg without debug data
Comment 4 Ralf Kaestner 2008-04-02 10:44:31 UTC
Created attachment 15575 [details]
dmesg output with cpufreq-debug=7
Comment 5 Ralf Kaestner 2008-04-02 10:45:15 UTC
Created attachment 15576 [details]
dump of the related sysfs parts
Comment 6 Ralf Kaestner 2008-04-02 10:45:59 UTC
Created attachment 15577 [details]
content of /proc/acpi/dsdt
Comment 7 Ralf Kaestner 2008-04-02 10:46:35 UTC
Created attachment 15578 [details]
output  of acpidump (hex data)
Comment 8 Ralf Kaestner 2008-04-02 10:47:48 UTC
Created attachment 15579 [details]
the suspicious acpi table error extracted from dmesg/messages
Comment 9 Ralf Kaestner 2008-04-02 10:48:15 UTC
Created attachment 15580 [details]
content of /proc/cpuinfo
Comment 10 Alexander Clouter 2008-04-02 10:54:46 UTC
Smells like the same problem I'm suffering:

http://bugzilla.kernel.org/show_bug.cgi?id=9919
Comment 11 Ralf Kaestner 2008-04-02 11:03:16 UTC
thanks a lot for that info, sounds very similar. acpi_osi=!Window2006 as kernel arg sounds as a nice workaround to me, will try that right now, or are there any gotchas that I've missed?
Comment 12 Ralf Kaestner 2008-04-02 11:14:16 UTC
looks like "bingo"
you made my day buddy!

giving acpi_osi="!Window2006" as kernel arg fixes the problem.
Comment 13 Alexander Clouter 2008-04-02 11:17:38 UTC
WARNING WILL ROBINSON DANGER DANGER

This is not a fix at least on my laptop.  Suspend/Resume one works for one cycle, I lose the cute beeps of the ACPI bits and some other ACPI functionality goes icky.

Worth making sure you can still do anything.  I personally prefer to be able to suspend/resume over get 400Mhz higher speeds on a nasty x86 box... :)
Comment 14 Ralf Kaestner 2008-04-02 11:55:40 UTC
thx, I got that, anyhow - suspend/resume is not even working at all on my laptop (will test that later) So I will test this Anti-V*sta option for a while and leave the bug open as reference. kernel dev may decide to close it as duplicate of 9919. However, seems that the Lifebook W 8010 needs some blacklisting as well. The acpi table error mentioned in comment #8 is gone with putting the acpi_osi option in.
Comment 15 Thomas Renninger 2008-04-02 12:15:46 UTC
The message:
ACPI Error (tbinstal-0134): Table has invalid signature [    ], must be SSDT, PSDT or OEMx [20070126]

Comes from the visit table (see the other bug)which is missing the "SSDT" in the table header.
This is clearly a BIOS bug.
The table is not loaded when osi=!Winows 2006 is passed.

These machines are so similar, I mark the bugs as duplicates now.
Comment 16 Thomas Renninger 2008-04-02 12:16:02 UTC

*** This bug has been marked as a duplicate of bug 9919 ***