From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: RE: RE: RE: RE: RE: No C-States any longer... Date: Wed, 15 Jun 2011 09:06:38 -0400 Message-ID: <20110615130638.GD5512@dumpdata.com> References: <5531913.201308128638769.JavaMail.root@uhura> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <5531913.201308128638769.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: "Tian, Kevin" , xen-devel , Ian Campbell , "Yu, Ke" List-Id: xen-devel@lists.xenproject.org On Wed, Jun 15, 2011 at 11:03:58AM +0200, Carsten Schiers wrote: > Thanks for your support. > > So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) natively, without Xen, and check > what acpi.debug and my printks are reporting? > > Would the other check be to change pr_id from -1 to 0 by some helper code in the right place? > > Have I correctly understood that my BIOS seems to implement C-States through FADT instead of _CST, > which is ok generally, but the FADT PBLK is not correctly set (maybe because it worries about the -1)? So the FADT PBLK is about this line: Processor (CP00, 0x10, 0x00000410, 0x06) in your DSDT. The 0x0000410 is the PBLK and somehow it is NULL on your box. You could run iasl -d on the DSDT to find out what exactly is there. But I *think* that should not affect the C-states as it is just used for reserving some CardBus regions. > > By the way: > > - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in xend-config.sxp > - I used Xen/Debian Squeeze PVOPS Xen Kernel on the Intel Box > - The same combo fails on the AMD box, latest PVOPS, too. Further testing done with latest PVOPS. So just so that you don't lose heart - the C states do work on my AMD box. Interstingly the _PSS states are being reported as non-existent - but on baremetal they seem to exist.