[Xen-devel] Re: Problem with booting 2.6.32.16 pvops DomU

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

On 07/07/2010 02:07 AM, Carsten Schiers wrote:
> 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
>   

Do you get any other console output?  Could you boot with
"earlyprink=xen" (and "console=hvc0" if you don't already) on the kernel
command line to see if any more comes out.

Those two MSRs relate to the K8 performance counter subsystem, but I
can't see any obviously relevent changes in 2.6.32.15->16 which might
cause this regression.

It might also be useful to use xenctx to work out where the hang is.

Thanks,
    J

>
> 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