[Xen-devel] Problem with booting 2.6.32.16 pvops DomU

[Carsten Schiers <carsten@xxxxxxxxxx>]

Hi,

I tried to boot a 64 Bit 2.6.32.16 pvops DomU from Jeremy's git on Xen 
3.4.4-rc1-pre 
and 64 Bit 2.6.18.8 Dom0.

It will hang very quickly after 0.5 secs and produce the following output on xm 
dmesg:

(XEN) traps.c:2230:d25 Domain attempted WRMSR 00000000c0010004 from 
00009310:79804ace to 00000000:00000000

(XEN) traps.c:2230:d25 Domain attempted WRMSR 00000000c0010000 from 
00000009:0487e489 to 00000000:00430076


BR,
Carsten.



----- Originalnachricht -----
Von: Carsten Schiers <carsten@xxxxxxxxxx>
Gesendet: Mon, 5.7.2010 11:09
An: xen-devel@xxxxxxxxxxxxxxxxxxx
Betreff: [Xen-devel] Question on xenpm

Dear all,

after having upgraded my server from AMD 4050e to X4 640, I now use cpufreq=xen 
and had
to adapt a munin script (monitoring tool) to display the residency in the 
different P-states.
This script uses /sys/device/system/cpu/cpu0/cpufreq to read out the 
information, whereas
I now use xenpm get-cpufreq-state.

Before I noticed that the CPU is in highest possible P-state (lowest 
frequences) nearly all 
of the time, and a minimal percentage in the lowest. Now I can see a 50/50 
distribution. 
Interesting enough, the xenpm get-cpuidle-state will show that the CPUs are at 
aprox. 90%
in C1 idle state.

Can there be a difference in how the two methods to collect the info are 
working? I mean 
something like xenpm will not count residency when in C1, but cpufreq driver 
will normaly
do?

BR,
Carsten.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel