From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Problem with booting 2.6.32.16 pvops DomU Date: Wed, 07 Jul 2010 08:34:26 -0700 Message-ID: <4C349E82.30100@goop.org> References: <3119103.71278493658977.JavaMail.root@uhura> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3119103.71278493658977.JavaMail.root@uhura> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Carsten Schiers Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 > Gesendet: Mon, 5.7.2010 11:09 > An: xen-devel@lists.xensource.com > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > >