Bug 11352 - Frequency Scaling working in Windows but not in Linux with MSI Fuzzy GME965
Summary: Frequency Scaling working in Windows but not in Linux with MSI Fuzzy GME965
Status: REJECTED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 high
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-16 02:13 UTC by Juan Antonio Garcia
Modified: 2008-08-20 17:47 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.24.19
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
The BIOS DSDT disasse,bled (211.03 KB, text/plain)
2008-08-16 02:23 UTC, Juan Antonio Garcia
Details
BIOS dump with acpidump (148.33 KB, application/octet-stream)
2008-08-18 09:59 UTC, Juan Antonio Garcia
Details
dmesg output with cpufreq.debug=7 (29.75 KB, text/plain)
2008-08-18 10:04 UTC, Juan Antonio Garcia
Details
Output of cat /proc/cpuinfo (1.21 KB, text/plain)
2008-08-18 10:06 UTC, Juan Antonio Garcia
Details

Description Juan Antonio Garcia 2008-08-16 02:13:12 UTC
Latest working kernel version: none
Earliest failing kernel version: none
Distribution: Ubuntu 8.04
Hardware Environment: Motherboard MSI FUzzy GME965 with Processor Intel Penryn T9300
Software Environment:
Problem Description: The Speed Step feature is not detected with this motherboard and BIOS release 1.20. No Throttling steps detected. The CPU is working permanently at full speed, bringing up the temperature of the server. The CPU does not use other states than the C0 state.

In Windows the frequency scaling is working properly.

Steps to reproduce:

It happens permanently.
Comment 1 Juan Antonio Garcia 2008-08-16 02:23:21 UTC
Created attachment 17274 [details]
The BIOS DSDT disasse,bled

Dump of BIOS version 1.20 for this motherboard
Comment 2 Juan Antonio Garcia 2008-08-16 02:23:56 UTC
I attach the disassembled DSDT for the last BIOS from AMI for this board.
The BIOS version release given by MSI is 1.20.

I don't know which part would be interesting to post in-line so I post the CPU part that might help for checking duplicate bugs.

    Scope (_PR)
    {
        Processor (P001, 0x01, 0x00000810, 0x06) {}
        Alias (P001, CPU1)
    }

    Scope (_PR)
    {
        Processor (P002, 0x02, 0x00000810, 0x06) {}
        Alias (P002, CPU2)
    }
Comment 3 ykzhao 2008-08-17 07:12:58 UTC
Will you please attach the output of acpidump?(Not only dsdt table).
It will be great if you can add the boot option of "cpufreq.debug=7" and attach the output of dmesg. (Of course you should enable the CONFIG_CPUFREQ_DEBUG in kernel configuration.)
Thanks.
Comment 4 Juan Antonio Garcia 2008-08-18 09:59:13 UTC
Created attachment 17306 [details]
BIOS dump with acpidump

This is the BIOS dump with:

acpidump > biosdump.bin

The reply of the command is: Wrong checksum for generic table!
Comment 5 Juan Antonio Garcia 2008-08-18 10:04:12 UTC
Created attachment 17307 [details]
dmesg output with cpufreq.debug=7

I attach the dmesg output when booting with the kernel with CONFIG_CPU_FRQ_DEBUG activated.
Comment 6 Juan Antonio Garcia 2008-08-18 10:06:57 UTC
Created attachment 17308 [details]
Output of cat /proc/cpuinfo

I attach the output of cat /proc/cpuinfo
Comment 7 ykzhao 2008-08-18 18:51:44 UTC
Hi, Juan
   Thanks for the info. 
   It seems that this issue is related with the BIOS. There is no _PSS/_PCT/_PPC object in acpi table, which is required by acpi_cpufreq driver. As the CPU is Penryn T9300, the speedstep-ich cpufreq driver is also inappropriate. In such case no cpufreq driver is loaded successfully. So the cpufreq scaling can't work in Linux. 
   Will you please check whether there exists the BIOS option related with cpufreq in BIOS ? If yes, please enable it and see whether it can work.
   At the same time there is no _CST/_CSD object and the C2/C3 latency defined in FADT table is above the predefined max latency. So the C-states also can't work on this system. 
    >C2 Latency : 0065  The max latency for C2 is 100.
    >C3 Latency : 03E9  The max latency for C3 is 1000.

   But it is strange that cpufreq scaling can work on windows. Maybe the addition SSDT table is provided on windows, on which the _PSS/_PCT/_PPC object is defined. 
   Will you please check whether there is new version BIOS?
   
   In the dmesg log there exists the following message:
  > [   44.199399] Error attaching device data
  > [   44.199459] Error attaching device data
   Will you please try the latest kernel (for example : 2.6.26) and see whether the message still exists?

  Thanks. 
Comment 8 Juan Antonio Garcia 2008-08-20 09:07:16 UTC
Hi Yakui,

no settings in the BIOS about the CPU frequency scaling. So as you found out clearly it is not supported by the BIOS.
To test that the CPU frequency scaling was working in Windows I used a tool that showed around 800MHz, so I conclude that CPU scaling was working. When you mention that it was funny it worked in Windows I downloaded a more advanced tool and the results is that it is not working neither in Windows. So clearly it is a BIOS issue. My test was wrong, it seems the first tool needed to refresh a few times till it showed the correct value.

Sorry to give wrong information.
I have reported this issue to MSI who is the manufacturer.
So it is clear then there is no issue.

MSI does not seem to be very active, so I would like to have your advice here.
Would it be possible I write the missing methods in a DSDT table and I get support for frequency scaling?
I know I can write an alternative DSDT, and in Windows I can force the CPU clock to lower down.

For the FADT I have no clue if that could be done?

Thanks,

Juan
Comment 9 Juan Antonio Garcia 2008-08-20 11:08:40 UTC
I have tested kernel 2.6.26.2 and the messages:
Error attaching device data

do not appear any more.
Comment 10 ykzhao 2008-08-20 17:47:14 UTC
   Thanks for the confirm and your efforts.
   From your test it seems that cpufreq scaling also can't work on windows.
   If you add the _PPC/_PSS/_PCT object for every cpu, maybe cpufreq scaling can work on your system. But it is difficult. The definition in _PSS/_PPC/_PCT object is related with hardware.
  For example: The the definition of _PCT object is :
    Name (_PCT, Package(){
   >    ResourceTemplate(){Perf_Ctrl_Register},
   >    ResourceTemplate(){Perf_Status_Register} 
    }) // End of _PCT 
    The above register definition is related with BIOS. 

   It will be better that you report this issue to MSI and wait for their response. It is difficutl to write a custom DSDT for this machine.

   As the bug is related with BIOS and cpufreq scaling also can't work on windows, it will be rejected.
   Thanks.

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