Carsten Schiers
2011-Jun-15 09:03 UTC
AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
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)? 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. Everything used to work with Xen / 2.6.18 Dom0 Kernel, but I cannot check that, because it will not boot any longer, because it doesn''t find the root system. I currently concentrate on the C-State issue. Carsten. ----- Originalnachricht ----- Von: "Tian, Kevin" <kevin.tian@intel.com> Gesendet: Mit, 15.6.2011 10:39 An: Ian Campbell <Ian.Campbell@citrix.com> Cc: Carsten Schiers <carsten@schiers.de> ; "Yu, Ke" <ke.yu@intel.com> ; xen-devel <xen-devel@lists.xensource.com> 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 > > 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 PBLK > > > (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? > > 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 disconnection.> > 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 != -1 case. > > 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 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 other corner cases we didn''t capture. But since this works on his Intel box, which I guess same configuration is used, I''d think it may come from some oddity in AMD box''s ACPI table which is not well handled by either common ACPI code or Xen specific stubs. Thanks Kevin> > This changeset refers to the -1 too: > > commit 68320323a51c2378aca433c76157d9e66104ff1e > Author: Jiang, Yunhong <yunhong.jiang@intel.com> > Date: Tue Sep 14 14:41:52 2010 -0700 > > xen/acpi: Add cpu hotplug support > > Add physical CPU hotplug support to origin/xen/next-2.6.32 branch. > Please notice that, even with this change, the acpi_processor->id is > still always -1. This is because several workaround in PM side depends > on acpi_processor->id == -1. As the CPU hotplug logic does not depends > on acpi_processor->id, I''d still keep it no changes. > > But we need change the acpi_processor->id in the future. > > Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > Ian. > > > > 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_info with > xen > > specific tweaks added. there''s possibility that in your environment general > ACPI code > > is changed which is not reflected in Xen specific versions. > > > > Thanks > > Kevin > > > > > > > > Carsten. > > > > > > -----Ursprüngliche 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... > > > > > > >>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 100% > > > 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-15 13:06 UTC
Re: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-15 13:17 UTC
AW: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
>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.Very intersting, as P-States work perfectly with my AMD box... Cheers, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-15 16:22 UTC
Re: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
On Wed, Jun 15, 2011 at 09:06:38AM -0400, Konrad Rzeszutek Wilk wrote:> 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.Or maybe not:http://www.coreboot.org/ACPI _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-15 18:00 UTC
AW: Re: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
>> But I *think* that should not affect the C-states as it is just usedfor reserving some>> CardBus regions. > >Or maybe not:http://www.coreboot.org/ACPIThat''s where I got my information from. So wither we have a problem in accessing the tables (very unprobable ) or the logic has changed between 2.6.18.8 and 2.6.32-pvops what happens If a BIOS doesn''t provide C-State information at all... Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-16 02:06 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Wednesday, June 15, 2011 5:04 PM > > 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?yes> > Would the other check be to change pr_id from -1 to 0 by some helper code in > the right place?In the native case pr->id can be -1 only under CPU hotplug case, or else it should be a valid number in all cases. In Xen due to the difference between dom0''s VCPU and underlying PCPU, the extra logic is added to retrieve ACPI object even when pr->id is -1.> > 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)?I checked ACPI spec again. PBLK is an optional processor control block though it''s generally implemented in most platforms. It includes system I/O port address which can be used to throttle CPU clock or enter C2/C3 in a static manner. When the BIOS provides _CST methods which is a more flexible and preferred way to carry Cstate information, PBLK is not used. Or else PBLK provides basic information to control C-state, and FADT table contains latency info about C2/C3 So if your platform BIOS reports ACPI table correctly, I would expect: - either there''s a valid _CST existing - or there''s a valid PBLK info which is accompanied with valid Cstate info in FADT In your case there''s no _CST found, and then no PBLK found. So the code simply early returns w/o further acquiring FADT info: static int acpi_processor_get_power_info_fadt(struct acpi_processor *pr) { if (!pr) return -EINVAL; if (!pr->pblk) return -ENODEV;> > By the way: > > - I dom0_vcpus_pin and restrict Dom0 to only use one vcpu in > xend-config.sxpSo you can try use same VCPU number as physical number, to see whether this issue is caused by the mismatch.> - 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.do you mean the latest PVOPS from Konzad? I don''t think Cstate/Pstate patches have been carried there, which still stay in Jeremy''s tree. Since this is the AMD box which I''m not familiar with, also CC Mark here who is the owner for power management on AMD boxes.> > Everything used to work with Xen / 2.6.18 Dom0 Kernel, but I cannot check that, > because it will not > boot any longer, because it doesn''t find the root system. I currently > concentrate on the C-State > issue. >Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-16 02:12 UTC
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, June 15, 2011 9:07 PM > > 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.Just a caveat that manual iasl may not match the actual content observed by the kernel, because OSPM may notify BIOS for its supported capability which then may further impact final visible content. :-) Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Konrad Rzeszutek Wilk
2011-Jun-16 13:32 UTC
Re: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> > - The same combo fails on the AMD box, latest PVOPS, too. Further testing > > done with latest PVOPS. > > do you mean the latest PVOPS from Konzad? I don''t think Cstate/Pstate patches > have been carried there, which still stay in Jeremy''s tree.I stuck them in the stable/2.6.39.x tree. They they do need some refactoring for them be upstreamable. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-16 19:33 UTC
AW: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
>> 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?>>yesBooting the very kernel on bare hardware will not change the way things are running, despite one small change: the CPUs are registered as "cooling devices" ?!? [ 3.568766] ACPI: Power Button [PWRF] [ 3.734140] acpi_processor_get_power_info called [ 3.734200] acpi_processor_get_power_info zeroes all c-states [ 3.734260] acpi_processor_get_power_info analyzes cst [ 3.734319] acpi_processor_get_power_info_cst called [ 3.734377] acpi_processor_get_power_info_cst conted [ 3.734436] acpi_processor_get_power_info_cst bad cst [ 3.734495] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.734556] acpi_processor_get_power_info analyzes fadt [ 3.734614] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.734675] acpi_processor_get_power_info we have a result [ 3.734774] processor LNXCPU:00: registered as cooling_device0 [ 3.734855] acpi_processor_get_power_info called [ 3.734912] acpi_processor_get_power_info zeroes all c-states [ 3.734973] acpi_processor_get_power_info analyzes cst [ 3.735031] acpi_processor_get_power_info_cst called [ 3.735089] acpi_processor_get_power_info_cst conted [ 3.735147] acpi_processor_get_power_info_cst bad cst [ 3.735206] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735267] acpi_processor_get_power_info analyzes fadt [ 3.735325] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735386] acpi_processor_get_power_info we have a result [ 3.735463] processor LNXCPU:01: registered as cooling_device1 [ 3.735542] acpi_processor_get_power_info called [ 3.735599] acpi_processor_get_power_info zeroes all c-states [ 3.735659] acpi_processor_get_power_info analyzes cst [ 3.735717] acpi_processor_get_power_info_cst called [ 3.735775] acpi_processor_get_power_info_cst conted [ 3.735834] acpi_processor_get_power_info_cst bad cst [ 3.735892] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735954] acpi_processor_get_power_info analyzes fadt [ 3.736013] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.736074] acpi_processor_get_power_info we have a result [ 3.736305] processor LNXCPU:02: registered as cooling_device2 I did a cat on /proc/acpi/processor/cpu0 files: info ---- processor id: 0 acpi id: 0 bus mastering control: yes power management: no throttling control: no limit interface: no limit: <not supported> power: ------ active state: C0 max_cstate: C8 maximum allowed latency: 2000000000 usec states: throttling: ----------- <not supported> Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-17 01:30 UTC
RE: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
It then implicates the possibility of a general bug in ACPI on this special AMD box, which then gets fixed in later kernel (so why Konrad''s 2.6.39 tree works). It''s not Xen/Dom0 specific. I suggest you move to Konrad''s tree when it''s ready. Thanks Kevin From: Carsten Schiers [mailto:carsten@schiers.de] Sent: Friday, June 17, 2011 3:34 AM To: Tian, Kevin Cc: Ian.Campbell; Yu, Ke; mark.langsdorf; xen-devel Subject: AW: RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...>> 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?>>yesBooting the very kernel on bare hardware will not change the way things are running, despite one small change: the CPUs are registered as "cooling devices" ?!? [ 3.568766] ACPI: Power Button [PWRF] [ 3.734140] acpi_processor_get_power_info called [ 3.734200] acpi_processor_get_power_info zeroes all c-states [ 3.734260] acpi_processor_get_power_info analyzes cst [ 3.734319] acpi_processor_get_power_info_cst called [ 3.734377] acpi_processor_get_power_info_cst conted [ 3.734436] acpi_processor_get_power_info_cst bad cst [ 3.734495] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.734556] acpi_processor_get_power_info analyzes fadt [ 3.734614] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.734675] acpi_processor_get_power_info we have a result [ 3.734774] processor LNXCPU:00: registered as cooling_device0 [ 3.734855] acpi_processor_get_power_info called [ 3.734912] acpi_processor_get_power_info zeroes all c-states [ 3.734973] acpi_processor_get_power_info analyzes cst [ 3.735031] acpi_processor_get_power_info_cst called [ 3.735089] acpi_processor_get_power_info_cst conted [ 3.735147] acpi_processor_get_power_info_cst bad cst [ 3.735206] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735267] acpi_processor_get_power_info analyzes fadt [ 3.735325] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735386] acpi_processor_get_power_info we have a result [ 3.735463] processor LNXCPU:01: registered as cooling_device1 [ 3.735542] acpi_processor_get_power_info called [ 3.735599] acpi_processor_get_power_info zeroes all c-states [ 3.735659] acpi_processor_get_power_info analyzes cst [ 3.735717] acpi_processor_get_power_info_cst called [ 3.735775] acpi_processor_get_power_info_cst conted [ 3.735834] acpi_processor_get_power_info_cst bad cst [ 3.735892] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.735954] acpi_processor_get_power_info analyzes fadt [ 3.736013] acpi_processor_get_power_info result=-19, -ENODEV=-19 [ 3.736074] acpi_processor_get_power_info we have a result [ 3.736305] processor LNXCPU:02: registered as cooling_device2 I did a cat on /proc/acpi/processor/cpu0 files: info ---- processor id: 0 acpi id: 0 bus mastering control: yes power management: no throttling control: no limit interface: no limit: <not supported> power: ------ active state: C0 max_cstate: C8 maximum allowed latency: 2000000000 usec states: throttling: ----------- <not supported> Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel