http://bugzilla.novell.com/show_bug.cgi?id=527800 User jbeulich@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c2 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low Severity|Major |Minor --- Comment #2 from Jan Beulich 2009-08-10 01:43:31 MDT --- First of all, we don't support cpufreq=dom0-kernel. Next, none of the native kernel cpufreq utilities are Xen-enabled. Finally, I'm not certain xenpm is fully functional in 3.3.x (and specifically for AMD CPUs). And the patch you mention above should, afaict, affect Intel CPUs only. In any case, using cpufreq=xen *does* have an effect on Fam10 CPUs as one can observe by watching the /proc/cpuinfo output. If that's not the case for you, please provide Xen+kernel boot output (Xen started with loglvl=all guest_loglvl=all). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c3 pgnet Dev changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|pgnet.dev@gmail.com | --- Comment #3 from pgnet Dev 2009-08-10 08:59:21 MDT --- hi jan,

we don't support cpufreq=dom0-kernel. none of the native kernel cpufreq utilities are Xen-enabled. I'm not certain xenpm is fully functional in 3.3.x (and specifically for AMD CPUs). the patch you mention above should, afaict, affect Intel CPUs only.

strikes on all counts :-/

using cpufreq=xen *does* have an effect on Fam10 CPUs as one can observe by watching the /proc/cpuinfo output. If that's not the case for you, please provide Xen+kernel boot output (Xen started with loglvl=all guest_loglvl=all).

you're correct, it _is_ the case, as can be seen here in /proc/cpuinfo ... cat /proc/cpuinfo | egrep -i "processor|MHz" processor : 0 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 800.000 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 4294967.294 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 2 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 4294967.294 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 3 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 4294967.294 power management: ts ttp tm stc 100mhzsteps hwpstate still, @ xenpm get-scaling-governor Xen cpuidle is not enabled! [CPU0] failed to get P-states statistics information [CPU1] failed to get P-states statistics information [CPU2] failed to get P-states statistics information [CPU3] failed to get P-states statistics information xenpm set-scaling-governor powersave Xen cpuidle is not enabled! [CPU0] failed to get P-states statistics information [CPU1] failed to get P-states statistics information [CPU2] failed to get P-states statistics information [CPU3] failed to get P-states statistics information so it appears it 'has an effect', but is not controllable? is that a version-of-xen problem? if so then I presume that the problem will also exist in SLES 11/11.1? perhaps something that can be fixed/backported? or, are we relegated to building (well, trying and likley failing ...) xen34x from src? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c5 --- Comment #5 from pgnet Dev 2009-08-10 09:53:15 MDT ---

...

cpu MHz : 4294967.294

are certainly odd (and wrong).

agreed.

As to xenpm functionality - I'm not even sure it's properly wired up for AMD in -unstable. But even if it is, the changes are too extensive to be considered for a backport.

understood. unfortunate, but ... checking @ http://www.suse.de/~coolo/factory-status.html, Name Devel Project Maintainer Failing Requests Version Upstream Comment .. xen Virtualization charlesa 2 d Project.diff in devel project 3.4.1_19711_01 3.4.0 python moved .. the *xen version* is @ least new enough. reading @ http://wiki.xensource.com/xenwiki/xenpm, "the default governor is userspace governor. Xen also supports three CPU drivers: ACPI (IA32) for Intel x86 processor; ACPI (IA64) for Intel Itanium processor and PowerNow K8 for AMD processor." seems to imply AMD *is* supported. however, if the wiring you're referring to is that "in *suse", then i've no clue ... nonetheless, important to have, i'd suggest.

So bottom line is, all originally brought up issues are unlikely to be fixed,

ok, so we have to live with defaults for now. given that, per xen wiki (for which version applicable, who knows?), "The default is the hypervisor based cpufreq", I rm'd "cpufreq=xen" from the grub boot line ... expecting that behavior, from above, should not change. BUT, cat /proc/cpuinfo | egrep -i "proc|mhz" processor : 0 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 2800.080 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 2800.080 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 2 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 2800.080 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 3 model name : AMD Phenom(tm) II X4 920 Processor cpu MHz : 2800.080 power management: ts ttp tm stc 100mhzsteps hwpstate shows that it does. and, xenpm get-scaling-governor Xen cpuidle is not enabled! Xen cpufreq is not enabled! so, are we 'back' to vanilla, non-xen Dom0 pm? apparently not, cpufreq-info cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU analyzing CPU 1: no or unknown cpufreq driver is active on this CPU analyzing CPU 2: no or unknown cpufreq driver is active on this CPU analyzing CPU 3: no or unknown cpufreq driver is active on this CPU so is, or isn't, opensuse-xen's cpufreq=xen active as a/the default? at the very least, i'd suggest that whatever state the default is should not appear broken ...

only this last issue is something we ought to look into.

happy to provide whatinfo i can ... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c7 --- Comment #7 from pgnet Dev 2009-08-10 11:08:51 MDT --- hm ... there are, apparently. xen 3.4.1 pkgs _built_ for opensuse 11.1, cref @, https://build.opensuse.org/package/show?package=xen&project=Virtualization but i'll be darned if i can _find_ them. any hints? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c9 --- Comment #9 from pgnet Dev 2009-08-10 17:52:05 MDT --- in an oh-what-the-heck moment, i installed the 341x rpms @ Dom0, rebooted and, uname -ri 2.6.27.29-7-xen x86_64 rpm -qa | grep -i xen xen-doc-pdf-3.4.1_19711_01-9.1 kernel-xen-2.6.27.29-7.1 xen-3.4.1_19711_01-9.1 kernel-xen-extra-2.6.27.29-7.1 xen-devel-3.4.1_19711_01-9.1 kernel-xen-2.6.27.29-6.1 xen-doc-html-3.4.1_19711_01-9.1 kernel-xen-base-2.6.27.29-7.1 xen-libs-3.4.1_19711_01-9.1 xen-tools-3.4.1_19711_01-9.1 and, xm dmesg __ __ _____ _ _ _ _ ___ _____ _ _ ___ _ ___ _ \ \/ /___ _ __ |___ /| || | / | / |/ _ \___ / / | / _ \/ | / _ \ / | \ // _ \ '_ \ |_ \| || |_ | | | | (_) | / /| | | | | | | |_| (_) || | / \ __/ | | | ___) |__ _|| | | |\__, |/ / | | | | |_| | |__\__, || | /_/\_\___|_| |_| |____(_) |_|(_)_|___|_| /_//_/ |_|_|___\___/|_| /_(_)_| |_____| |_____| (XEN) Xen version 3.4.1_19711_01-9.1 (abuild@) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) Wed Aug 5 01:48:18 UTC 2009 (XEN) Latest ChangeSet: 19711 (XEN) Command line: dom0_mem=768M cpufreq=xen loglvl=all loglvl_guest=all vga=gfx-1280x1024x32 console=vga,com1 com1=57600,8n1 .. then, @ Dom0, xenpm get-scaling-governor xen power management control tool usage: xenpm <command> [args] xenpm command list: get-cpuidle-states [cpuid] list cpu idle info of CPU <cpuid> or all get-cpufreq-states [cpuid] list cpu freq info of CPU <cpuid> or all get-cpufreq-para [cpuid] list cpu freq parameter of CPU <cpuid> or all set-scaling-maxfreq [cpuid] <HZ> set max cpu frequency <HZ> on CPU <cpuid> or all CPUs set-scaling-minfreq [cpuid] <HZ> set min cpu frequency <HZ> on CPU <cpuid> or all CPUs set-scaling-speed [cpuid] <num> set scaling speed on CPU <cpuid> or all it is used in userspace governor. set-scaling-governor [cpuid] <gov> set scaling governor on CPU <cpuid> or all as userspace/performance/powersave/ondemand set-sampling-rate [cpuid] <num> set sampling rate on CPU <cpuid> or all it is used in ondemand governor. set-up-threshold [cpuid] <num> set up threshold on CPU <cpuid> or all it is used in ondemand governor. get-cpu-topology get thread/core/socket topology info set-sched-smt enable|disable enable/disable scheduler smt power saving set-vcpu-migration-delay <num> set scheduler vcpu migration delay in us get-vcpu-migration-delay get scheduler vcpu migration delay set-max-cstate <num> set the C-State limitation (<num>

= 0) start [seconds] start collect Cx/Px statistics, output after CTRL-C or SIGINT or several seconds.

hey, no error! checking, xenpm set-scaling-governor ondemad xenpm get-cpufreq-para cpu id : 0 affected_cpus : *0 1 2 3 cpuinfo frequency : max [2800000] min [800000] cur [800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : powersave scaling_avail_freq : 2800000 2100000 1600000 *800000 scaling frequency : max [2800000] min [800000] cur [800000] cpu id : 1 affected_cpus : 0 *1 2 3 cpuinfo frequency : max [2800000] min [800000] cur [800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : powersave scaling_avail_freq : 2800000 2100000 1600000 *800000 scaling frequency : max [2800000] min [800000] cur [800000] cpu id : 2 affected_cpus : 0 1 *2 3 cpuinfo frequency : max [2800000] min [800000] cur [800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : powersave scaling_avail_freq : 2800000 2100000 1600000 *800000 scaling frequency : max [2800000] min [800000] cur [800000] cpu id : 3 affected_cpus : 0 1 2 *3 cpuinfo frequency : max [2800000] min [800000] cur [800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : powersave scaling_avail_freq : 2800000 2100000 1600000 *800000 scaling frequency : max [2800000] min [800000] cur [800000] and, cat /proc/cpuinfo | grep MHz cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 cpu MHz : 800.000 looks promising. changing, xenpm set-scaling-governor performance xenpm get-cpufreq-para cpu id : 0 affected_cpus : *0 1 2 3 cpuinfo frequency : max [2800000] min [800000] cur [2800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : performance scaling_avail_freq : *2800000 2100000 1600000 800000 scaling frequency : max [2800000] min [800000] cur [2800000] cpu id : 1 affected_cpus : 0 *1 2 3 cpuinfo frequency : max [2800000] min [800000] cur [2800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : performance scaling_avail_freq : *2800000 2100000 1600000 800000 scaling frequency : max [2800000] min [800000] cur [2800000] cpu id : 2 affected_cpus : 0 1 *2 3 cpuinfo frequency : max [2800000] min [800000] cur [2800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : performance scaling_avail_freq : *2800000 2100000 1600000 800000 scaling frequency : max [2800000] min [800000] cur [2800000] cpu id : 3 affected_cpus : 0 1 2 *3 cpuinfo frequency : max [2800000] min [800000] cur [2800000] scaling_driver : scaling_avail_gov : userspace performance powersave ondemand current_governor : performance scaling_avail_freq : *2800000 2100000 1600000 800000 scaling frequency : max [2800000] min [800000] cur [2800000] NOTE the as-expected change from cur[800000] to cur[2800000] and, cat /proc/cpuinfo | grep MHz cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 cpu MHz : 2800.000 finally, launching a release-version DomU (i.e., Xen 3.3.1), boots with no apparent errors, dmesg Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.27.29-7-xen (geeko@buildhost) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP 2009-08-05 21:29:36 +0200 Command line: root=/dev/xvdc1 textmode=1 xencons=xvc0 swiotlb=128,force elevator=noop linuxrc=trace debug ... progress! perhpas xen 3.4.1 _can_ find it's way back into 11.1, officially ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c11 --- Comment #11 from pgnet Dev 2009-08-11 14:54:40 MDT --- hm. i'd hope that PM _has_ some interest in functional xen power mgmt on 11.1. if only to benefit from freedback from a broader community (commercial customer and otherwise) that tests on 11.1. if not, could we at _least_ get those pkgs -- that are clearly being built -- released & published into a working repository that we can install from & track? also, i wonder if/when 3.4.1-based fixes, then, will make it back into a SP for my licensed SLES installs. if they don't -- presuming the truth of "... changes are too extensive to be considered for a backport ..." -- PowerManagement in SLES, may well have it's own 'challenges'. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c13 --- Comment #13 from pgnet Dev 2009-08-13 16:38:19 MDT --- daniel,

After booting into xen:

what cpufreq/cpuidle settings do you have in grub for xen hypervisor? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c15 pgnet Dev changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |dcollingridge@novell.com --- Comment #15 from pgnet Dev 2009-08-14 10:12:28 MDT --- hi dan, i'm missing something ... in #12, above, you report, After booting into xen: processor : 0 model name : Six-Core AMD Opteron(tm) Processor 2427 cpu MHz : 2200.038 but in your attachment, === Then after setting cpufreq=xen, xenpm get-scaling-governor === === cat /proc/cpuinfo | egrep -i "processor|MHz" === processor : 0 cpu MHz : 800.000 power management: ts ttp tm stc 100mhzsteps hwpstate what's the difference between the two scenarios? also, how are you running xenpm get-scaling-governor afaict, it's not an available option for xenpm ... finally, fwiw, my workaround to get xenpm settings to 'stick' across boot is to, simply, enable them late in boot, i.e, echo "xenpm set-scaling-governor ondemand" >> /etc/init.d/boot.local echo "xenpm set-scaling-governor performance" >> /etc/init.d/boot.local cd /etc/init.d/rc3.d ln -sf ../boot.local S100boot.local requiring BOTH the set- settings :-/ clearly, here, something's not healthy with the initialization ... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User pgnet.dev@gmail.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c17 --- Comment #17 from pgnet Dev 2009-08-14 10:59:02 MDT --- dan, (In reply to comment #16)

The difference is that in the first one (snip)

thanks for clarifying.

I've emailed the machine details to Jan. Hopefully he'll be able to take a look at it soon.

appreciated, thanks. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User jbeulich@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c19 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |pgnet.dev@gmail.com --- Comment #19 from Jan Beulich 2009-08-17 04:29:28 MDT --- I can't see anything leading to a value of 0xfffffffe being returned for the frequency (and error would result in zero being returned, which in turn would result in the frequency determined at boot time getting output). Please attach a full hypervisor+kernel boot log (collected via serial using cpufreq=xen loglvl=all guest_loglvl=all on the Xen command line) plus the small fragment of /var/log/messages that relates to that boot, making sure you still see those odd frequencies after boot. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User jbeulich@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c21 --- Comment #21 from Jan Beulich 2009-08-18 00:37:23 MDT --- Please clarify whether you want to stick with 11.1 here (in which case it was outlined above what problem there might need addressing) or whether you want to use a mixture of all sorts of software (in which case we'll just close this report as not being applicable). Btw., using the performance governor it is certainly expected that the system would run at full speed almost all of the time; you'd have to use the on-demand governor to see it reduce clock speeds more frequently. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=527800 User jbeulich@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=527800#c23 --- Comment #23 from Jan Beulich 2009-08-18 10:07:35 MDT --- The only thing we'll support 11.1-wise is 11.1 kernel + 11.1 hypervisor (including most recent updates), or all Factory software. We simply can't help you in any way if you want to mix 11.1 and Factory, and have a problem with that combination. As to power management not working in 11.1 - you confirmed yourself that this is not the case. What is not working is a helper utility. Whether we can fix this depends on the scope of the needed fix, and here the scope of backporting 3.4.1's cpufreq code is simply too large. Hence, the only thing we would consider looking into is the bogus frequency output. For everything beyond, we'll have to defer you to 11.2. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.