Latest working kernel version: 2.6.22.9 (-0.3, I think) Earliest failing kernel version: 2.6.22.12-0.1 Distribution: OpenSUSE 10.3 Hardware Environment: AMD Athlon™ 64 X2 Dual Core Processor 6000+ on AM2 ASRock 2xDDR2 ALiveNF7G-HDReady VSL 7050/630a Software Environment: OpenSUSE 10.3 Problem Description: When I recently upgraded the kernel from 2.6.22.9 (-0.3, I think) to 2.6.22.12-0.1 via yast2 suddenly the cpufreq feature of the power management stopped working. It was working great before, with the CPU scaled down from 3 GHz to 1 GHz or so depending on the system load. kpowersave and ksensors confirmed this. I get the following messages in /var/log/messages Dec 7 08:43:49 hostname rchal: Cannot load cpufreq governors - No cpufreq driver available Dec 7 08:44:13 localhost powersaved[4604]: WARNING (CpufreqManagement:51) No capability cpufreq_control Dec 7 08:44:13 localhost powersaved[4604]: WARNING (CpufreqManagement:51) No capability cpufreq_control Since I have not done anything to the system except standard updates via yast2 from standard sources I do not believe that I have done anything to brake cpufreq. Upgrading to kernel 2.6.22.13-0.3 has brought no improvement, cpufreq is still broken. I tried to insmod these modules by hand: insmod /lib/modules/2.6.22.13-0.3-default/kernel/drivers/cpufreq/cpufreq_userspace.ko insmod /lib/modules/2.6.22.13-0.3-default/kernel/drivers/cpufreq/cpufreq_powersave.ko insmod /lib/modules/2.6.22.13-0.3-default/kernel/drivers/cpufreq/cpufreq_stats.ko insmod /lib/modules/2.6.22.13-0.3-default/kernel/drivers/cpufreq/cpufreq_conservative.ko They apparently load OK in the kernel and are displayed by lsmod, however, this has no effect on the CPU frequency. /etc/init.d/powersaved status shows that the daemon that is probably responsible for CPU frequency scaling is running. CPU and other hardware are unchanged. Now I have run out of ideas. I therefore suppose this is a kernel bug? Steps to reproduce: Upgrade kernel as above.
try loading acpi_cpufreq, which is a "cpufreq driver"
I tried that before, it does not work :-( root@localhost: /root -> lsmod | fgrep acpi Exit 1 root@localhost: /root -> insmod /lib/modules/2.6.22.13-0.3-default/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko insmod: error inserting '/lib/modules/2.6.22.13-0.3-default/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko': -1 No such device Exit 1 root@localhost: /root ->
Here is the output from /var/log/messages (first few lines) Jan 9 08:39:50 hostname syslog-ng[2508]: syslog-ng version 1.6.12 starting Jan 9 08:39:50 hostname SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled. Jan 9 08:39:51 hostname SuSEfirewall2: batch committing... Jan 9 08:39:51 hostname rchal: CPU frequency scaling is not supported by your processor. Jan 9 08:39:51 hostname rchal: boot with 'CPUFREQ=no' in to avoid this warning. Jan 9 08:39:51 hostname rchal: Cannot load cpufreq governors - No cpufreq driver available Jan 9 08:39:55 hostname kernel: klogd 1.4.1, log source = /proc/kmsg started. Jan 9 08:39:55 hostname kernel: AppArmor: AppArmor initialized Jan 9 08:39:55 hostname kernel: audit(1199864386.064:2): type=1505 info="AppArmor initialized" pid=2245 Jan 9 08:39:55 hostname kernel: NET: Registered protocol family 10 Jan 9 08:39:55 hostname kernel: lo: Disabled Privacy Extensions Jan 9 08:39:55 hostname kernel: Mobile IPv6 Jan 9 08:39:55 hostname syslog-ng[2508]: Changing permissions on special file /dev/xconsole Jan 9 08:39:55 hostname syslog-ng[2508]: Changing permissions on special file /dev/tty10 Jan 9 08:39:55 hostname kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team Jan 9 08:39:55 hostname kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jan 9 08:39:55 hostname kernel: Netfilter messages via NETLINK v0.30. Jan 9 08:39:55 hostname kernel: nf_conntrack version 0.5.0 (8192 buckets, 65536 max) Jan 9 08:39:55 hostname kernel: powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ processors (version 2.00.00) Jan 9 08:39:55 hostname kernel: powernow-k8: MP systems not supported by PSB BIOS structure Jan 9 08:39:55 hostname kernel: powernow-k8: MP systems not supported by PSB BIOS structure
This is possibly related to bug 8075 (q.v.)? http://bugzilla.kernel.org/show_bug.cgi?id=8075
oops, this is an AMD box. rather than acpi-cpufreq, please try to load powernow-k7 or powernow-k8.
Created attachment 14410 [details] Output of dmesg on my machine where cpufreq fails, kernel 2.6.22.13-0.3-default (OpenSuSE, x86-64, AMD)
First of all, thanks for working on this! (In reply to comment #5) > oops, this is an AMD box. > rather than acpi-cpufreq, please try to load powernow-k7 or powernow-k8. > In this case it does not matter because it fails with the same error message: root@localhost: /root -> modprobe powernow-k8 FATAL: Error inserting powernow_k8 (/lib/modules/2.6.22.13-0.3-default/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko): No such device Exit 1 Whatever "device" is needed apparently is broken. Which module writes the "rchal: CPU frequency scaling is not supported by your processor." message (see above)? That is the first error in /var/log/messages, the powernow-k8 message comes afterwards. In case you are wondering, by the way, I have made no BIOS upgrade or changed any setting in the BIOS at the time cpufreq broke. Somewhere I read something about IOMMU (whatever that is) but my BIOS does not have any such option. Well, it has worked before with the same BIOS, so it cannot be that anyway, am I right? I am attaching the output of dmesg in the hope that it will help to clear things up... Many thanks and regards, Ned.
Do you need more information?
Solved! In the past few days I kept experimenting, installing old and new kernels and so on. Today I reset my BIOS settings to "Optimal Default" values and thereby re-enabled CPU frequency scaling! I have no idea which option caused the malfunction, there is certainly no option to disable it (I would not disable it - I am not that thick!). Currently (in its working state) the options "ACPI HPET table" and "Windows Media Center Away Mode support" (they may be related?) are disabled. Apologies for not finding this earlier! I do not remember to have changed any setting at the time of the kernel upgrade when the problem first occured, except maybe the boot sequence. Thanks for bearing with me! Ned.
I experimented some more and could track it to the "AM2 Boost" option. When I enable it, cpufreq does not work! This does not make a lot of sense to me, but then I do not know much about the way the kernel modules interact with the chipset... Apparently I had enabled that option at the same time when I upgraded the kernel, without remembering it now -- or, the older kernel versions worked even with that option enabled! That question is still unanswered. Maybe someone who knows how these things work could comment on it? Does AM2Boos necessarily disable cpufreq functionality, or should it really work?
Hi, Ned Will you please enable the debug function of acpi and cpufreq and add the boot option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x17 cpufreq.debug=7"? Please attach the output of acpidump and dmesg. Thanks.
Created attachment 15004 [details] dmesg output, no am2boost => cpufreq works
Created attachment 15005 [details] acpidump output, no am2boost => cpufreq works
Created attachment 15006 [details] dmesg output, am2boost enabled in BIOS => cpufreq does not work
Created attachment 15007 [details] acpidump output, am2boost enabled in BIOS => cpufreq does not work
Dear Yakui Zhao, Thanks very much for your reply. I have attached the files as requested, once with AM2BOOST enabled in the BIOS, then cpufreq does not work, once with AM2BOOST disabled in the BIOS, then cpufreq works. I hope this helps to track down the problem. Kind regards, Ned.
Hi, Ned Thanks for the info. According to the log in comment #12 and #14 it seems that the problem is related with the option of "AM2BOOT". When AM2BOOT option enabled in BIOS, there is no definition of _PSS, _PSD, _PCT. If _PSS/_PCT don't exist, the power-k8 driver can't be loaded successfully. So cpufreq scaling can't work. But when AM2BOOT option disabled in BIOS, there exists SSDT table in which _PSS,_PSD and _PCT are defined. So the cpufreq scaling can work normally. This problem is related with BIOS and it will be rejected.
Hi, venki, this problem is caused by the bios configuration. IMO, the bug can be closed.
okay, lets close this as a BIOS issue -- unless there is some proof that the old kernel worked even in the face of this BIOS option. thanks.