Bug 207595
| Summary: | cpuspeed can't be started with Opteron 285 processors | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Thomas Schwanhäuser <thomas.schwanhaeuser> |
| Component: | kernel | Assignee: | Jarod Wilson <jarod> |
| Status: | CLOSED CANTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | bnagendr, j, tjb |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-26 22:05:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Thomas Schwanhäuser
2006-09-21 19:32:10 UTC
Have you tried just running "cpuspeed" as root to see if it produces any error messages? None of my opterons support frequency scaling under FC5: compute19:~> s cpuspeed Error: Could not open file for writing: /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor Error: No such file or directory Error: Could not open file for writing: /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor Error: No such file or directory Error: Could not open file for writing: /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor Error: No such file or directory Error: Could not open file for writing: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Error: No such file or directory (Dual dual-core Opteron 280 machine here.) The boot messages indicated that scaling is unsupported: compute19:~> dmesg|grep -i power powernow-k8: Found 4 AMD Athlon 64 / Opteron processors (version 1.60.2) powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] I wouldn't expect cpuspeed to start up any daemons if there's nothing that can actually be scaled, so it seems that its behavior is appropriate here. Hi Jason, get the same results on the 285 OPterons with the commands from you: [root@web2 ~]# cpuspeed Error: Could not open file for writing: /sys/devices/system/cpu/cpu1/cpufreq/scaling_governorError: Could not open file for writing: /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor Error: No such file or directory Error: No such file or directory Error: Could not open file for writing: /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor Error: No such file or directory Error: Could not open file for writing: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Error: No such file or directory [root@web2 ~]# dmesg|grep -i power powernow-k8: Found 4 AMD Athlon 64 / Opteron processors (version 1.60.2) powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure powernow-k8: MP systems not supported by PSB BIOS structure ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] But the BIOS supports actually PowerNow. On the same mainboard and also Fedora Core 5, but with a 265 processor, I get: [root@mgmt-1 ~]# uname -a Linux mgmt-1 2.6.17-1.2187_FC5 #1 SMP Mon Sep 11 01:16:59 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux [root@mgmt-1 ~]# dmesg|grep -i power ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x00000000cff16eba powernow-k8: Found 2 AMD Athlon 64 / Opteron processors (version 1.60.2) powernow-k8: 0 : fid 0xa (1800 MHz), vid 0x8 (1350 mV) powernow-k8: 1 : fid 0x2 (1000 MHz), vid 0x12 (1100 mV) ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] [root@mgmt-1 ~]# service cpuspeed status cpuspeed (pid 1419 1418) is running... [root@mgmt-1 ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 265 stepping : 2 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 2010.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 265 stepping : 2 cpu MHz : 1000.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 2010.91 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp Best regards, Thomas So I guess the point is that this isn't actually a bug in cpuspeed, unless you consider that it should probably log something about its failure to find any CPUs it can manage. The question of why the powernow driver doesn't think it can scale any of the recent processors is something for the kernel folks, I'd say. I'd sure like to do this myself, as a rack full of dual and quad dual-core Opteron systems sure dumps a lot of heat and uses a ton of power that could be saved by slowing things down when possible. AMD64 systems don't run cpuspeed, unless the 'userspace' governor is selected. By default, AMD64 systems should use the cpufreq-ondemand kernel-level cpu frequency scaling governor. The cpuspeed initscript in recent rawhide cpuspeed builds has updated logic to give better feedback to indicate what's actually going on. As for the "powernow-k8: MP systems not supported by PSB BIOS structure" error messages, it looks like the powernow-k8 bits didn't yet know what to do with the Opteron 285 processors. Please retest with the latest kernel to see if we didn't pick up support in 2.6.18 or later... Fairly certain this was a lack of kernel-level support in the powernow-k8 module, moving bug to kernel component and leaving open as NEEDINFO. I just updated from a single core Athon 64 to a Dual Core Opteron 185 and have hit this same problem. I'm running the latest updates-testing 2.6.19-1.2895.fc6 kernel (in 32bit mode) and get the same "powernow-k8: MP systems not supported by PSB BIOS structure". So it may be that this is not a pure BIOS bug (which I think I have little chance of getting fixed) and may be a kernel driver bug that could be fixed? Hrm. Possibly a combination of lacking kernel-level support and bios-level support, but starting to look more like just bios-level support... Adding someone to the cc list who might know better than me... And might be able to point me towards some Opteron 285 or 185 processors... "powernow-k8: MP systems not supported by PSB BIOS structure" This message means that the BIOS does not support the necessary PSB tables without which Power Now! in a MP system cannot work. Several Tyan systems don't have this support in the BIOS. (In reply to comment #8) > "powernow-k8: MP systems not supported by PSB BIOS structure" > > This message means that the BIOS does not support the necessary PSB tables without > which Power Now! in a MP system cannot work. Several Tyan systems don't have > this support in the BIOS. What about in the case where powernow-k8 is happy with Opteron 265 processors, but not 285 processors, on the same motherboard? Hm... Just noticed that in the 265 case, there appears to be only one socket populated, versus two in the 285 case... Are the PSB BIOS structures technically more for multi-socket support, rather than multi-processor support? (Ah, the havoc multi-core cpus have wreaked on terminology... :) That is odd that they would work with 265 and not 285, however, the sockets need to be populated with identical processors. I have never left a socket open with no silicon, so can't comment on what effect that would have. Yes, the PSB BIOS table is for a multi core system. In desperation, I flashed a newer beta BIOS and now cpu scaling works again. Same kernel, new BIOS. One of the featuers of the BIOS was FX-60 support, which I believe is essentially the same as the Opteron 185. Okay, so far as I understand it, this is solely a BIOS support issue. If the system w/the 285 procs that fails to do freq scaling but succeeds with a pair of 265 procs, we may have something and the bug can be reopened, but it appears that was not the case. Closing CANTFIX, on the belief its a BIOS problem. |