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.
Created attachment 17274 [details] The BIOS DSDT disasse,bled Dump of BIOS version 1.20 for this motherboard
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) }
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.
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!
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.
Created attachment 17308 [details] Output of cat /proc/cpuinfo I attach the output of cat /proc/cpuinfo
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.
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
I have tested kernel 2.6.26.2 and the messages: Error attaching device data do not appear any more.
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.