Bug 9919
| Summary: | acpi_osi="!Windows 2006" else cpufreq breaks - Fujitsu T2010 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Alexander Clouter (alex) |
| Component: | Power-Processor | Assignee: | ykzhao (yakui.zhao) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, nokos, ralf.kaestner, trenn |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.24 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
patch to add runtime DMI based OSI interface disabling
patch to add the Fujitsu Lifebook T2010 to the blacklist acpidump spiel for the Fujitsu Lifebook T2010 acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist 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 acpidump --addr 0x7F6CDAFC --length 0x35A -o vist *without* acpi_osi="!Windows 2006" passed *with* acpi_osi="!Windows 2006" passed try the debug patch |
||
Created attachment 14761 [details]
patch to add runtime DMI based OSI interface disabling
Created attachment 14762 [details]
patch to add the Fujitsu Lifebook T2010 to the blacklist
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? Gah, I mean changed to === acpi_osi_invalidate(str); printk(KERN_INFO PREFIX "Deleted _OSI(%s)\n", str); === please attach the acpidump output from the failing system 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)
}
=======
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... :) 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. Created attachment 14855 [details]
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist
Created attachment 14856 [details]
acpidump --addr 0x7f6cacd0 --length 0x1f6 -o cpu0ist
Created attachment 14857 [details]
acpidump --addr 0x7f6cb118 --length 0xb8 -o cpu1ist
Created attachment 14858 [details]
acpidump --addr 0x7f6cb1d0 --length 0x5cd -o cpu0cst
Created attachment 14859 [details]
acpidump --addr 0x7f6cb798 --length 0xb8 -o cpu1cst
Will you please attach the following output? acpidump --addr 0x7F6CDAFC --length 0x35A -o vist Thanks. Created attachment 14912 [details]
acpidump --addr 0x7F6CDAFC --length 0x35A -o vist
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". 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) :) 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
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.
*** Bug 10383 has been marked as a duplicate of this bug. *** 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. similar problem in S6410 see bug 10454. 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.
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.
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 *** Bug 10454 has been marked as a duplicate of this bug. *** |
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