From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Schiers Subject: AW: RE: RE: RE: RE: RE: No C-States any longer... Date: Wed, 15 Jun 2011 11:03:58 +0200 Message-ID: <5531913.201308128638769.JavaMail.root@uhura> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Tian, Kevin" , Ian Campbell Cc: xen-devel , "Yu, Ke" List-Id: xen-devel@lists.xenproject.org Thanks for your support.=20 So the plan is to run the very kernel (2.6.32.40 from Jeremy's git) nativ= ely, without Xen, and check=20 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 thro= ugh FADT instead of _CST,=20 which is ok generally, but the FADT PBLK is not correctly set (maybe beca= use it worries about the -1)? By the way:=20 - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in xend-confi= g.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 testi= ng done with latest PVOPS. Everything used to work with Xen / 2.6.18 Dom0 Kernel, but I cannot check= that, because it will not=20 boot any longer, because it doesn't find the root system. I currently con= centrate on the C-State=20 issue. Carsten. ----- Originalnachricht ----- Von: "Tian, Kevin" Gesendet: Mit, 15.6.2011 10:39 An: Ian Campbell Cc: Carsten Schiers ; "Yu, Ke" ; x= en-devel Betreff: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer... > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Sent: Wednesday, June 15, 2011 4:35 PM >=20 > On Wed, 2011-06-15 at 09:11 +0100, Tian, Kevin wrote: > > > From: Carsten Schiers [mailto:carsten@schiers.de] > > > Sent: Tuesday, June 14, 2011 4:27 AM > > > > > > One step further: the problem is that pr->pblk is not set, thus > > > acpi_processor_get_power_info_fadt fails. > > > Knowing this, I found an error in the ACPI_DEBUG output that > > > corresponds: > > > > > > [ 17.062739] processor_xen-0222 [00] xen_acpi_processor_get: > Processor > > > [-1:0] > > > [ 17.062902] processor_xen-0225 [00] xen_acpi_processor_get: No P= BLK > > > (NULL address) > > > > this looks a bit strange. how about the native log? > > > > > > > > It does this for all processors. pr_id is always -1, pr->acpi_id > > > counting up from 0 to 2. > > > > what's your dom0 vcpu number? and how about physical cpu? >=20 > Wasn't there some oddity in the Xen ACPI PM support due to the > disconnect between VCPU and PCPU? I thought it resulted in some CPU id > or other being reported back as -1, in much this manner. yes, the existing tricky changes are mostly used to tackle this disconnec= tion. >=20 > There's some tweaking of this stuff in e.g. > xen_acpi_processor_get_power_info(). But equally > xen_acpi_processor_get_info() has a bunch of cases for the !=3D -1 case= =2E >=20 > Does the dom0_vcpus_pin hypervisor option workaround this sort of thing= ? We don't want to add that limitation to have dom0 vcpu number same as=20 physical cpu number to use PM features. But yes Carsten can try use same number to see whether it works for him. If it works, then there's ot= her corner cases we didn't capture. But since this works on his Intel box, wh= ich I guess same configuration is used, I'd think it may come from some oddit= y in AMD box's ACPI table which is not well handled by either common ACPI code or Xen specific stubs. Thanks Kevin >=20 > This changeset refers to the -1 too: >=20 > commit 68320323a51c2378aca433c76157d9e66104ff1e > Author: Jiang, Yunhong > Date: Tue Sep 14 14:41:52 2010 -0700 >=20 > xen/acpi: Add cpu hotplug support >=20 > Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. > Please notice that, even with this change, the acpi_processor->id i= s > still always -1. This is because several workaround in PM side depe= nds > on acpi_processor->id =3D=3D -1. As the CPU hotplug logic does not d= epends > on acpi_processor->id, I'd still keep it no changes. >=20 > But we need change the acpi_processor->id in the future. >=20 > Signed-off-by: Jiang, Yunhong > Signed-off-by: Jeremy Fitzhardinge = >=20 > Ian. >=20 > > > Any help is welcome, but I will analyze further... > > > > Current Dom0 depends on several Xen specific functions like > xen_acpi_get_power_info > > you mentioned earlier, which is a copy from native acpi_get_power_inf= o with > xen > > specific tweaks added. there's possibility that in your environment g= eneral > ACPI code > > is changed which is not reflected in Xen specific versions. > > > > Thanks > > Kevin > > > > > > > > Carsten. > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Carsten Schiers > > > Gesendet: Montag, 13. Juni 2011 15:22 > > > An: ke.yu; kevin.tian > > > Cc: xen-devel > > > Betreff: AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer= =2E.. > > > > > > >>I will try to boot native Linux in order to verify 100% > > > >> that the tables > > > >> are there. > > > > > > > >yes, that's interesting data to compare. > > > > > > I have booted with a Live Linux and dumped acpi tables. Those are 1= 00% > > > identical with those > > > I received from Dom0. I will now start looking into > > > acpi_processor_get_power_info_fadt And > > > check, why it is returning -ENODEV. > > > > > > Carsten. > > > > > > > > > _______________________________________________ > > > Xen-devel mailing list > > > Xen-devel@lists.xensource.com > > > http://lists.xensource.com/xen-devel > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com > > http://lists.xensource.com/xen-devel >=20