Bug 9919 - acpi_osi="!Windows 2006" else cpufreq breaks - Fujitsu T2010
acpi_osi="!Windows 2006" else cpufreq breaks - Fujitsu T2010
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Processor
All Linux
: P1 normal
Assigned To: ykzhao
:
: 10383 10454 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-08 16:57 UTC by Alexander Clouter
Modified: 2008-06-18 18:33 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.24
Tree: Mainline
Regression: ---


Attachments
patch to add runtime DMI based OSI interface disabling (1.52 KB, patch)
2008-02-08 16:57 UTC, Alexander Clouter
Details | Diff
patch to add the Fujitsu Lifebook T2010 to the blacklist (559 bytes, patch)
2008-02-08 16:58 UTC, Alexander Clouter
Details | Diff
acpidump spiel for the Fujitsu Lifebook T2010 (150.26 KB, application/octet-stream)
2008-02-09 02:14 UTC, Alexander Clouter
Details
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist (1.45 KB, application/octet-stream)
2008-02-16 03:26 UTC, Alexander Clouter
Details
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist (502 bytes, application/octet-stream)
2008-02-16 03:28 UTC, Alexander Clouter
Details
acpidump --addr 0x7f6cb118 --length 0xb8 -o cpu1ist (184 bytes, application/octet-stream)
2008-02-16 03:28 UTC, Alexander Clouter
Details
acpidump --addr 0x7f6cb1d0 --length 0x5cd -o cpu0cst (1.45 KB, application/octet-stream)
2008-02-16 03:29 UTC, Alexander Clouter
Details
acpidump --addr 0x7f6cb798 --length 0xb8 -o cpu1cst (184 bytes, application/octet-stream)
2008-02-16 03:29 UTC, Alexander Clouter
Details
acpidump --addr 0x7F6CDAFC --length 0x35A -o vist (858 bytes, application/octet-stream)
2008-02-20 03:59 UTC, Alexander Clouter
Details
*without* acpi_osi="!Windows 2006" passed (15.94 KB, application/octet-stream)
2008-02-27 11:48 UTC, Alexander Clouter
Details
*with* acpi_osi="!Windows 2006" passed (9.54 KB, application/octet-stream)
2008-02-27 11:49 UTC, Alexander Clouter
Details
try the debug patch (1.76 KB, patch)
2008-05-27 01:51 UTC, ykzhao
Details | Diff

Description Alexander Clouter 2008-02-08 16:57:04 UTC
Hardware Environment: Fujitsu T2010

The DSDT table has some magic Vista extra 'functionality' that after about thirty seconds of uptime forces the CPU to sit at it's rock bottom frequency.  Annoying.

The fix is simple, pass 'acpi_osi="!Windows 2006"' to the kernel and the problem disappears.  This of course is horrible so I turned to drivers/acpi/blacklist.c and added some useful (well I think so) functionality.

I have attached a patch that lets you put into blacklist.c the following:

=========
{
.callback = dmi_invalidate_osi,
.ident = "Fujitsu Lifebook T2010",
.matches = {
        DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
        DMI_MATCH(DMI_PRODUCT_NAME, "LifeBook T2010"),
    },
.driver_data = "Windows 2006\0\0",
},

driver_data contains a NULL byte seperated list of OSI interfaces you want to disable at runtime, the list is terminated with two NULL bytes.  So another example would be "Windows 2006\0Windows 2001\0\0"...but not for my laptop :)

I'll attach the patches to this bug report once I have created it, please consider it for inclusion; or point me to the Right Way(tm) to do it :)

Cheers
Comment 1 Alexander Clouter 2008-02-08 16:57:58 UTC
Created attachment 14761 [details]
patch to add runtime DMI based OSI interface disabling
Comment 2 Alexander Clouter 2008-02-08 16:58:49 UTC
Created attachment 14762 [details]
patch to add the Fujitsu Lifebook T2010 to the blacklist
Comment 3 Alexander Clouter 2008-02-09 01:59:26 UTC
Looking at the patch to add this functionality, it's worth changing:

===
if (acpi_osi_invalidate(str) == AE_OK)
  printk(KERN_INFO PREFIX "Deleted _OSI(%s)\n", str);
===

to

===
printk(KERN_INFO PREFIX "Deleted _OSI(%s)\n", str);
===

As in blacklist.c only valid OSI names are ever going to go in there...right?
Comment 4 Alexander Clouter 2008-02-09 02:00:15 UTC
Gah, I mean changed to

===
acpi_osi_invalidate(str);
printk(KERN_INFO PREFIX "Deleted _OSI(%s)\n", str);
===
Comment 5 Len Brown 2008-02-09 02:05:47 UTC
please attach the acpidump output from the failing system
Comment 6 Alexander Clouter 2008-02-09 02:14:41 UTC
Created attachment 14763 [details]
acpidump spiel for the Fujitsu Lifebook T2010

Unsure how useful this would be actually, the 'interesting' bit seems to be in some alternative memory location.  If you can tell me how to dump the bits from 
0x7F6CDAFC (size 0x35A) then do let me know.

In the DSDT there is:
=====
OperationRegion (VIST, SystemMemory, 0x7F6CDAFC, 0x0000035A)
...
If (\_OSI ("Windows 2006"))
                    {
                        Store (0x40, ^OSTB)
                        Store (0x40, ^TPOS)
                    }
...
If (LGreaterEqual (\_SB.OSTP (), 0x40))
            {
                Load (VIST, VSTH)
            }
=======
Comment 7 Alexander Clouter 2008-02-14 16:28:34 UTC
An interesting side effect of acpi_osi="!Windows 2006" seems to be that after a suspend-to-ram/resume cycle I no longer receive and LID events (although I do receive power button ACPI events).

I need to look into this to be certain though.  Just noting it here incase anyone else is seeing similar issues.

So I have two choices, 1200MHz or suspend-to-RAM when I close my lid... :)
Comment 8 ykzhao 2008-02-14 19:07:43 UTC
Hi, Alexander
Will you please use the following command and attach the outpus?
  acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist
  acpidump --addr 0x7f6cb118 --length 0xb8  -o cpu1ist
  acpidump --addr 0x7f6cb1d0 --length 0x5cd -o cpu0cst
  acpidump --addr 0x7f6cb798 --length 0xb8  -o cpu1cst

Thanks.
  
Comment 9 Alexander Clouter 2008-02-16 03:26:31 UTC
Created attachment 14855 [details]
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist
Comment 10 Alexander Clouter 2008-02-16 03:28:24 UTC
Created attachment 14856 [details]
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist
Comment 11 Alexander Clouter 2008-02-16 03:28:55 UTC
Created attachment 14857 [details]
acpidump --addr 0x7f6cb118 --length 0xb8  -o cpu1ist
Comment 12 Alexander Clouter 2008-02-16 03:29:12 UTC
Created attachment 14858 [details]
acpidump --addr 0x7f6cb1d0 --length 0x5cd -o cpu0cst
Comment 13 Alexander Clouter 2008-02-16 03:29:39 UTC
Created attachment 14859 [details]
acpidump --addr 0x7f6cb798 --length 0xb8  -o cpu1cst
Comment 14 ykzhao 2008-02-20 01:49:46 UTC
Will you please attach the following output?
  acpidump --addr 0x7F6CDAFC --length 0x35A -o vist
Thanks.
Comment 15 Alexander Clouter 2008-02-20 03:59:39 UTC
Created attachment 14912 [details]
acpidump --addr 0x7F6CDAFC --length 0x35A -o vist
Comment 16 ykzhao 2008-02-21 01:12:24 UTC
Will you please try the debug patch in comment #8 of bug 9448 and enable the enable the debug function of cpufreq amd acpi in kernel configuration ? After the system is booted with the option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x1f cpufreq.debug=7", please do the following test.
    a. cd /sys/devices/system/cpu/cpu/cpu0/cpufreq && echo userspace > scaling_governor
    b. cat scaling_max_freq > scaling_setspeed
    c. echo performance > scaling_governor
    d. Wait for some time and get the dmesg output.
 
    It will be great if you can do the above test with the additional boot option of "acpi_osi=!Window2006".
    
     
Comment 17 Alexander Clouter 2008-02-27 10:05:18 UTC
Sorry for the slow reply, been a busy couple of days for me.

Testing this as we speak, I'm assuming you actually meant the patch in bug #9488?

Looks like by using "acpi_osi=!Window2006" I loose, in addition to the lack of lid events as described in comment #7, cute beep noises when suspending and resuming.  Really looks like my approach is a Bad Idea(tm) :)
Comment 18 Alexander Clouter 2008-02-27 11:48:43 UTC
Created attachment 15028 [details]
*without* acpi_osi="!Windows 2006" passed

Created with:

grep -e "\(freq-table\|cpufreq-core\|acpi-cpufreq\|processor_perflib-0125 \[00\] processor_get_platform\|userspace\):" /var/log/kern.log
Comment 19 Alexander Clouter 2008-02-27 11:49:23 UTC
Created attachment 15029 [details]
*with* acpi_osi="!Windows 2006" passed

Created with:

grep -e "\(freq-table\|cpufreq-core\|acpi-cpufreq\|processor_perflib-0125 \[00\] processor_get_platform\|userspace\):" /var/log/kern.log

No change after 50 minutes of running.
Comment 20 Thomas Renninger 2008-04-02 12:16:02 UTC
*** Bug 10383 has been marked as a duplicate of this bug. ***
Comment 21 Thomas Renninger 2008-04-02 12:37:18 UTC
The visit table (from comment #15) is missing the "SSDT" in the table header.
This is clearly a BIOS bug.
It has a backlight brightness method and USB wakeup functions included. The first might still work through a fujitsu specific ACPI driver (not sure now whether backlight control is included there.)
The table can still be disassembled correctly when overriding the first four bytes with "SSDT".
I doubt we can/should work-around this, even it may work on Windows, but Len/Bob should see this that vendors do such uglyness...

But the visit table is not related to cpufreq, this is just the table loading error seen in dmesg in bug #10383:
ACPI Error (tbinstal-0134): Table has invalid signature [    ], must be SSDT,
PSDT or OEMx [20070126]

Yakui could you see a relation between cpufreq (eventually PPC?) and OSTP (OS version variable), I can't see it or did you just guess?
I'd like to find out the difference between Vista and !Vista.
Comment 22 Peter Gruber 2008-04-14 10:42:41 UTC
similar problem in S6410 see bug 10454.
Comment 23 ykzhao 2008-05-27 01:51:23 UTC
Created attachment 16290 [details]
try the debug patch

Will you please try the debug patch and see whether the problem still exists?
On this laptop BIOS has an error that vista table has no signature(SSDT/OEMx) and it can't be loaded successfully. 
Because of this error some AML codes can't be executed correctly.
For example: 
    \_SB.INI {Method (_INI, 0, NotSerialized)
        {   \_SB.OSTP ()
            If (LGreaterEqual (\_SB.OSTP (), 0x40))
            {
                Load (VIST, VSTH)
            } 
            \_SB.FEXT.BINI () // because of the error, the BINI won't be executed.
    
    Please try the attached debug patch and see whether the problem still exists.
    Thanks.
Comment 24 ykzhao 2008-05-27 02:18:07 UTC
   From the AML code I can't find the direct relation between the cpufreq(_PPC object) and OSTP. But the _PPC object is related with the following variables, which are controlled by BIOS. Maybe there exists the indirect relation. 
    > TCDT, TCUT, PDAT, PSNM 
   
   At the same time when there is no boot option of acpi_osi!=windows2006, OSPM will try to load the SSDT table from the address of 0x7F6CDAFC( VIST table). But the VIST table has no signature, which causes that the vista table can't be loaded successfully. Of course some objects can't be found. For example: \_SB_.PCI0.GFX0.LCD_.BLNF
   Because of the above error, it causes that the following object can't be executed correctly.
   > Method (\_SB._INI, 0, NotSerialized)
        {
            \_SB.OSTP ()
            If (LGreaterEqual (\_SB.OSTP (), 0x40))
            {
                Load (VIST, VSTH)
            }// because of the error, the _INI object will exit directly.
            \_SB.FEXT.BINI () // BINI object can't be executed.
            \_SB.PCI0.LPCB.TINI () //TINI object can't be executed.
        }
     From the AML code it seems that the following variables are initialized in the TINI object.
    > TCDT, TCUT ( the two variables are related with the _PPC object)
   
    If the boot option of acpi_osi!=windows2006, OSPM won't load the vist table and the \_SB._INI object can be executed correctly. Of course the variables(TCDT,TUDT) can also be initialized correctly.

Hi, Peter
    Will you please try the debug patch in comment #23 and see whether the problem still exists? 
    In the debug patch OSPM will continue to load the table even when it has no signature.
    
    Thanks.
    
Comment 25 ykzhao 2008-06-18 18:27:38 UTC
There exists the simiar bug in novel bugzilla.
>https://bugzilla.novell.com/show_bug.cgi?id=396311
After the patch is applied, the cpufreq can work well even without the option of acpi_osi=!windows 2006. 

As the patch is merged into upstream kernel, the bug will be marked as the resolved.

commit bc45b1d39a925b56796bebf8a397a0491489d85c
Author: Bob Moore <robert.moore@intel.com>
Date:   Tue Jun 10 14:12:50 2008 +0800

    ACPICA: Ignore ACPI table signature for Load() operator
Comment 26 Len Brown 2008-06-18 18:33:31 UTC
*** Bug 10454 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.