after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. Seems to be a problem with ACPI. Can it be a BIOS problem (although it worked up to now) or is this not implemented? Thanks & BR, Carsten. Some infos: xm dmesg after xm debug-key c: -------------------------------- (XEN) ''c'' pressed -> printing ACPI Cx structures xenpm get-cpuidle-states 0 -------------------------- Max C-state: C7 cpu id : 0 total C-states : 0 idle time(ms) : 0 pc3 : [00000000000000000018 ms] pc6 : [00000000000000004294 ms] pc7 : [00000000000140733193 ms] cc3 : [00000000000000000000 ms] cc6 : [00000000000000000006 ms] xm info ------- host : data release : 2.6.32-5-xen-amd64 version : #1 SMP Thu May 19 01:16:47 UTC 2011 machine : x86_64 nr_cpus : 3 nr_nodes : 1 cores_per_socket : 3 threads_per_core : 1 cpu_mhz : 2210 hw_caps : 178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000 virt_caps : hvm total_memory : 4094 free_memory : 373 free_cpus : 0 xen_major : 4 xen_minor : 1 xen_extra : .0 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : unavailable xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle cpufreq=xen cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) cc_compile_by : root cc_compile_domain : cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 xend_config_format : 4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, 2011-06-04 at 17:18 +0100, Carsten Schiers wrote:> after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > Seems to be a problem with ACPI. > Can it be a BIOS problem (although it worked up to now) or is this not > implemented?It may not have been implemented when Debian took their snapshot of pvops for the Squeeze release or there may have been missing bugfixes. Can you try the latest xen.git#xen/stable-2.6.32?> Some infos:It might be interesting to see the equivalent on a working system. Also a complete dmesg from each case would be useful. Ian.> > xm dmesg after xm debug-key c: > -------------------------------- > (XEN) ''c'' pressed -> printing ACPI Cx structures > > xenpm get-cpuidle-states 0 > -------------------------- > Max C-state: C7 > > cpu id : 0 > total C-states : 0 > idle time(ms) : 0 > pc3 : [00000000000000000018 ms] > pc6 : [00000000000000004294 ms] > pc7 : [00000000000140733193 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000006 ms] > > xm info > ------- > host : data > release : 2.6.32-5-xen-amd64 > version : #1 SMP Thu May 19 01:16:47 UTC 2011 > machine : x86_64 > nr_cpus : 3 > nr_nodes : 1 > cores_per_socket : 3 > threads_per_core : 1 > cpu_mhz : 2210 > hw_caps : > 178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000 > virt_caps : hvm > total_memory : 4094 > free_memory : 373 > free_cpus : 0 > xen_major : 4 > xen_minor : 1 > xen_extra : .0 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 > hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : unavailable > xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle > cpufreq=xen > cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) > cc_compile_by : root > cc_compile_domain : > cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 > xend_config_format : 4 > > > > > _______________________________________________ > 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
Just to give you an update: already baked kernel, but didn''t succeed to boot it. Something with filesystems. But cannot check currently. I''ll keep you updated. BR, C. ----- Originalnachricht ----- Von: Ian Campbell <Ian.Campbell@citrix.com> Gesendet: Mon, 6.6.2011 10:31 An: Carsten Schiers <carsten@schiers.de> Cc: xen-devel <xen-devel@lists.xensource.com> Betreff: Re: [Xen-devel] No C-States any longer... On Sat, 2011-06-04 at 17:18 +0100, Carsten Schiers wrote:> after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > Seems to be a problem with ACPI. > Can it be a BIOS problem (although it worked up to now) or is this not > implemented?It may not have been implemented when Debian took their snapshot of pvops for the Squeeze release or there may have been missing bugfixes. Can you try the latest xen.git#xen/stable-2.6.32?> Some infos:It might be interesting to see the equivalent on a working system. Also a complete dmesg from each case would be useful. Ian.> > xm dmesg after xm debug-key c: > -------------------------------- > (XEN) ''c'' pressed -> printing ACPI Cx structures > > xenpm get-cpuidle-states 0 > -------------------------- > Max C-state: C7 > > cpu id : 0 > total C-states : 0 > idle time(ms) : 0 > pc3 : [00000000000000000018 ms] > pc6 : [00000000000000004294 ms] > pc7 : [00000000000140733193 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000006 ms] > > xm info > ------- > host : data > release : 2.6.32-5-xen-amd64 > version : #1 SMP Thu May 19 01:16:47 UTC 2011 > machine : x86_64 > nr_cpus : 3 > nr_nodes : 1 > cores_per_socket : 3 > threads_per_core : 1 > cpu_mhz : 2210 > hw_caps : > 178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000 > virt_caps : hvm > total_memory : 4094 > free_memory : 373 > free_cpus : 0 > xen_major : 4 > xen_minor : 1 > xen_extra : .0 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 > hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : unavailable > xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle > cpufreq=xen > cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) > cc_compile_by : root > cc_compile_domain : > cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 > xend_config_format : 4 > > > > > _______________________________________________ > 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
I tested with Xen 4.1.0 and latest xen.git#xen/stable-2.6.32: still not working. Find attached some files. I currently have no working system to produce equivalents. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Ian Campbell [mailto:Ian.Campbell@citrix.com] Gesendet: Montag, 6. Juni 2011 10:31 An: Carsten Schiers Cc: xen-devel Betreff: Re: [Xen-devel] No C-States any longer... On Sat, 2011-06-04 at 17:18 +0100, Carsten Schiers wrote:> after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > Seems to be a problem with ACPI. > Can it be a BIOS problem (although it worked up to now) or is this not> implemented?It may not have been implemented when Debian took their snapshot of pvops for the Squeeze release or there may have been missing bugfixes. Can you try the latest xen.git#xen/stable-2.6.32?> Some infos:It might be interesting to see the equivalent on a working system. Also a complete dmesg from each case would be useful. Ian.> > xm dmesg after xm debug-key c: > -------------------------------- > (XEN) ''c'' pressed -> printing ACPI Cx structures > > xenpm get-cpuidle-states 0 > -------------------------- > Max C-state: C7 > > cpu id : 0 > total C-states : 0 > idle time(ms) : 0 > pc3 : [00000000000000000018 ms] > pc6 : [00000000000000004294 ms] > pc7 : [00000000000140733193 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000006 ms] > > xm info > ------- > host : data > release : 2.6.32-5-xen-amd64 > version : #1 SMP Thu May 19 01:16:47 UTC 2011 > machine : x86_64 > nr_cpus : 3 > nr_nodes : 1 > cores_per_socket : 3 > threads_per_core : 1 > cpu_mhz : 2210 > hw_caps : >178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000> virt_caps : hvm > total_memory : 4094 > free_memory : 373 > free_cpus : 0 > xen_major : 4 > xen_minor : 1 > xen_extra : .0 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32> hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : unavailable > xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle > cpufreq=xen > cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) > cc_compile_by : root > cc_compile_domain : > cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 > xend_config_format : 4 > > > > > _______________________________________________ > 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
On Tue, Jun 07, 2011 at 10:16:48PM +0200, Carsten Schiers wrote:> I tested with Xen 4.1.0 and latest xen.git#xen/stable-2.6.32: still not > working.You seem to have ''cpuidle'' by itself. Shouldn''t it be ''cpuidle=xen'' ?> Find attached some files. I currently have no working system to produce > equivalents._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Sorry, wanted to emphasize on the following anomalies: xm dmesg: (XEN) traps.c:2375:d0 Domain attempted WRMSR 00000000c0010004 from 0x00007676727ffab2 to 0x0000000000000000. (XEN) traps.c:2375:d0 Domain attempted WRMSR 00000000c0010000 from 0x00000301181cccaf to 0x0000000000430076. (XEN) traps.c:2375:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d0 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d1 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d2 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d4 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d5 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d6 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d7 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d8 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d8 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d9 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d10 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. (XEN) traps.c:2375:d10 Domain attempted WRMSR 00000000c0010048 from 0x0000000000780000 to 0x0000000000780400. dmesg Dom0: [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-0 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ERROR: Unable to locate IOAPIC for GSI 2 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ERROR: Unable to locate IOAPIC for GSI 9 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) [ 0.000000] ERROR: Unable to locate IOAPIC for GSI 14 [ 0.000000] Using ACPI (MADT) for SMP configuration information ... [ 0.008500] ------------[ cut here ]------------ [ 0.008575] WARNING: at arch/x86/xen/enlighten.c:729 init_hw_perf_events+0x337/0x3d7() [ 0.008674] Hardware name: M56S-S3 [ 0.008741] Modules linked in: [ 0.008848] Pid: 0, comm: swapper Not tainted 2.6.32.40-xen-amd64 #2 [ 0.008922] Call Trace: [ 0.008993] [<ffffffff8104d73f>] ? warn_slowpath_common+0x76/0x8c [ 0.009071] [<ffffffff814e1113>] ? init_hw_perf_events+0x337/0x3d7 [ 0.009148] [<ffffffff814e0c20>] ? identify_boot_cpu+0x15/0x3d [ 0.009223] [<ffffffff814e0db7>] ? check_bugs+0x9/0x2e [ 0.009297] [<ffffffff814d9ce3>] ? start_kernel+0x3cb/0x3e5 [ 0.009371] [<ffffffff814dbb4e>] ? xen_start_kernel+0x5ae/0x5b4 [ 0.009450] ---[ end trace a7919e7f17c0a725 ]--- ... [ 0.049594] ERROR: Unable to locate IOAPIC for GSI 9 ... BR, Carsten. -----Ursprüngliche Nachricht----- Von: Ian Campbell [mailto:Ian.Campbell@citrix.com] Gesendet: Montag, 6. Juni 2011 10:31 An: Carsten Schiers Cc: xen-devel Betreff: Re: [Xen-devel] No C-States any longer... On Sat, 2011-06-04 at 17:18 +0100, Carsten Schiers wrote:> after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > Seems to be a problem with ACPI. > Can it be a BIOS problem (although it worked up to now) or is this not> implemented?It may not have been implemented when Debian took their snapshot of pvops for the Squeeze release or there may have been missing bugfixes. Can you try the latest xen.git#xen/stable-2.6.32?> Some infos:It might be interesting to see the equivalent on a working system. Also a complete dmesg from each case would be useful. Ian.> > xm dmesg after xm debug-key c: > -------------------------------- > (XEN) ''c'' pressed -> printing ACPI Cx structures > > xenpm get-cpuidle-states 0 > -------------------------- > Max C-state: C7 > > cpu id : 0 > total C-states : 0 > idle time(ms) : 0 > pc3 : [00000000000000000018 ms] > pc6 : [00000000000000004294 ms] > pc7 : [00000000000140733193 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000006 ms] > > xm info > ------- > host : data > release : 2.6.32-5-xen-amd64 > version : #1 SMP Thu May 19 01:16:47 UTC 2011 > machine : x86_64 > nr_cpus : 3 > nr_nodes : 1 > cores_per_socket : 3 > threads_per_core : 1 > cpu_mhz : 2210 > hw_caps : >178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000> virt_caps : hvm > total_memory : 4094 > free_memory : 373 > free_cpus : 0 > xen_major : 4 > xen_minor : 1 > xen_extra : .0 > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32> hvm-3.0-x86_32p hvm-3.0-x86_64 > xen_scheduler : credit > xen_pagesize : 4096 > platform_params : virt_start=0xffff800000000000 > xen_changeset : unavailable > xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle > cpufreq=xen > cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) > cc_compile_by : root > cc_compile_domain : > cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 > xend_config_format : 4 > > > > > _______________________________________________ > 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
I think it''s only cpuidle, but it doesn''t make a difference anyhow... ----- Originalnachricht ----- Von: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Gesendet: Die, 7.6.2011 22:21 An: Carsten Schiers <carsten@schiers.de> Cc: xen-devel <xen-devel@lists.xensource.com> ; Ian.Campbell <Ian.Campbell@citrix.com> Betreff: Re: Re: [Xen-devel] No C-States any longer... On Tue, Jun 07, 2011 at 10:16:48PM +0200, Carsten Schiers wrote:> I tested with Xen 4.1.0 and latest xen.git#xen/stable-2.6.32: still not > working.You seem to have ''cpuidle'' by itself. Shouldn''t it be ''cpuidle=xen'' ?> Find attached some files. I currently have no working system to produce > equivalents._______________________________________________ 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
I''m really not sure how this stuff is supposed to work. I''ve CC''d some Intel folks who authored/touched driver/acpi/processor_xen.c and drivers/xen/acpi_processor.c which I think is the glue which is supposed to make this stuff work. Ian. On Tue, 2011-06-07 at 21:16 +0100, Carsten Schiers wrote:> I tested with Xen 4.1.0 and latest xen.git#xen/stable-2.6.32: still not > working. > Find attached some files. I currently have no working system to produce > equivalents. > > BR, > Carsten. > > -----Ursprüngliche Nachricht----- > Von: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Gesendet: Montag, 6. Juni 2011 10:31 > An: Carsten Schiers > Cc: xen-devel > Betreff: Re: [Xen-devel] No C-States any longer... > > On Sat, 2011-06-04 at 17:18 +0100, Carsten Schiers wrote: > > after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > > Seems to be a problem with ACPI. > > Can it be a BIOS problem (although it worked up to now) or is this not > > > implemented? > > It may not have been implemented when Debian took their snapshot of > pvops for the Squeeze release or there may have been missing bugfixes. > Can you try the latest xen.git#xen/stable-2.6.32? > > > Some infos: > > It might be interesting to see the equivalent on a working system. Also > a complete dmesg from each case would be useful. > > Ian. > > > > > xm dmesg after xm debug-key c: > > -------------------------------- > > (XEN) ''c'' pressed -> printing ACPI Cx structures > > > > xenpm get-cpuidle-states 0 > > -------------------------- > > Max C-state: C7 > > > > cpu id : 0 > > total C-states : 0 > > idle time(ms) : 0 > > pc3 : [00000000000000000018 ms] > > pc6 : [00000000000000004294 ms] > > pc7 : [00000000000140733193 ms] > > cc3 : [00000000000000000000 ms] > > cc6 : [00000000000000000006 ms] > > > > xm info > > ------- > > host : data > > release : 2.6.32-5-xen-amd64 > > version : #1 SMP Thu May 19 01:16:47 UTC 2011 > > machine : x86_64 > > nr_cpus : 3 > > nr_nodes : 1 > > cores_per_socket : 3 > > threads_per_core : 1 > > cpu_mhz : 2210 > > hw_caps : > > > 178bf3ff:efd3fbff:00000000:00001310:00802001:00000000:000037ff:00000000 > > virt_caps : hvm > > total_memory : 4094 > > free_memory : 373 > > free_cpus : 0 > > xen_major : 4 > > xen_minor : 1 > > xen_extra : .0 > > xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 > > > hvm-3.0-x86_32p hvm-3.0-x86_64 > > xen_scheduler : credit > > xen_pagesize : 4096 > > platform_params : virt_start=0xffff800000000000 > > xen_changeset : unavailable > > xen_commandline : dom0_mem=256M dom0_vcpus_pin cpuidle > > cpufreq=xen > > cc_compiler : gcc version 4.4.5 (Debian 4.4.5-8) > > cc_compile_by : root > > cc_compile_domain : > > cc_compile_date : Fri Jun 3 17:03:43 CEST 2011 > > xend_config_format : 4 > > > > > > > > > > _______________________________________________ > > 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
> From: Carsten Schiers > Sent: Sunday, June 05, 2011 12:19 AM > > after my move to Xen 4.1.0 and Debian 2.6.32-5-xen-amd64 pvops Dom0. > Seems to be a problem with ACPI. > Can it be a BIOS problem (although it worked up to now) or is this not > implemented?to verify BIOS problem, you could run a native Linux to verify.> > Thanks & BR, Carsten. > > Some infos: > > xm dmesg after xm debug-key c: > -------------------------------- > (XEN) ''c'' pressed -> printing ACPI Cx structures > > xenpm get-cpuidle-states 0 > -------------------------- > Max C-state: C7 > > cpu id : 0 > total C-states : 0 > idle time(ms) : 0 > pc3 : [00000000000000000018 ms] > pc6 : [00000000000000004294 ms] > pc7 : [00000000000140733193 ms] > cc3 : [00000000000000000000 ms] > cc6 : [00000000000000000006 ms]This looks strange. At least C1 should be available. You may check Xen/dom0 log to see any error there, or manually add some printk in set_cx_pminfo to see any error there. Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> to verify BIOS problem, you could run a native Linux to verify.I can tell you that it worked with the old Xenified 2.6.18 kernel.> This looks strange. At least C1 should be available. You may checkXen/dom0> log to see any error there, or manually add some printk inset_cx_pminfo to> see any error there.I check tonight. Does it make sense also to turn debug info on for Dom0 acpi? BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Thursday, June 09, 2011 12:05 PM > > > to verify BIOS problem, you could run a native Linux to verify. > > I can tell you that it worked with the old Xenified 2.6.18 kernel.Then possibly some patches get lost in your current env...> > > This looks strange. At least C1 should be available. You may check > Xen/dom0 > > log to see any error there, or manually add some printk in > set_cx_pminfo to > > see any error there. > > I check tonight. Does it make sense also to turn debug info on for Dom0 > acpi? >You can have a try though I don''t think that gives much hint because basic ACPI logic doesn''t change in Dom0. The more interesting thing is about the gear logic between dom0 and Xen. Does the dom0 notify Xen on earth? Is there some condition making Xen reject the call? ... Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2011-06-09 at 05:04 +0100, Carsten Schiers wrote:> > to verify BIOS problem, you could run a native Linux to verify. > > I can tell you that it worked with the old Xenified 2.6.18 kernel.Perhaps there are CONFIG options needed for the new kernel which aren''t enabled? Can you post your .config please. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> The more interesting thing is > about the gear logic between dom0 and Xen. Does the dom0 notify > Xen on earth? Is there some condition making Xen reject the call? ...I am not sure whether this is a gear, but in dmesg I have a WARNING which is issued by enlighten.c/xen_apic_write, saying: Warn to see if there''s any stray reference.> You may check Xen/dom0 > log to see any error there, or manually add some printk in set_cx_pminfo to > see any error there.I''ll do that tonight, Kernel is already baking... BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2011-06-09 at 11:50 +0100, Carsten Schiers wrote:> > The more interesting thing is > > about the gear logic between dom0 and Xen. Does the dom0 notify > > Xen on earth? Is there some condition making Xen reject the call? ... > > I am not sure whether this is a gear, but in dmesg I have a WARNING > which is issued by enlighten.c/xen_apic_write, saying: Warn to see if there''s > any stray reference.Those are 99% likely to be benign.> > > You may check Xen/dom0 > > log to see any error there, or manually add some printk in set_cx_pminfo to > > see any error there. > > I''ll do that tonight, Kernel is already baking... > > BR, > 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
Through some adding of printk I was able at least to verify that for my 3 core CPU AMD Athlon X3 400e - xen_px_notifier is called six times - Hypervisor is reporting XEN_PM_PX is called six times - Hypervisor is never reporting XEN_PM_CX to have been called - this is because xen_cx_notifier is never called. -> set_cx_pminfo is never called. What I will try to find out next is to check where xen_cx_notifier *should* be called. OS debugging is not realy my expertise, let''s see whether you first can give me a hint or whether I am quicker to find it on my own. Carsten. -----Ursprüngliche Nachricht----- Von: Tian, Kevin [mailto:kevin.tian@intel.com] Gesendet: Donnerstag, 9. Juni 2011 06:19 An: Carsten Schiers; xen-devel Betreff: RE: RE: [Xen-devel] No C-States any longer...> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Thursday, June 09, 2011 12:05 PM > > > to verify BIOS problem, you could run a native Linux to verify. > > I can tell you that it worked with the old Xenified 2.6.18 kernel.Then possibly some patches get lost in your current env...> > > This looks strange. At least C1 should be available. You may check > Xen/dom0 > > log to see any error there, or manually add some printk in > set_cx_pminfo to > > see any error there. > > I check tonight. Does it make sense also to turn debug info on forDom0> acpi? >You can have a try though I don''t think that gives much hint because basic ACPI logic doesn''t change in Dom0. The more interesting thing is about the gear logic between dom0 and Xen. Does the dom0 notify Xen on earth? Is there some condition making Xen reject the call? ... Thanks Kevin _______________________________________________ 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
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Friday, June 10, 2011 3:09 AM > > Through some adding of printk I was able at least to verify that for my > 3 core CPU AMD Athlon X3 400e > > - xen_px_notifier is called six times > - Hypervisor is reporting XEN_PM_PX is called six times > - Hypervisor is never reporting XEN_PM_CX to have been called > - this is because xen_cx_notifier is never called. > -> set_cx_pminfo is never called. > > What I will try to find out next is to check where xen_cx_notifier > *should* be called. OS debugging is > not realy my expertise, let''s see whether you first can give me a hint > or whether I am quicker to find > it on my own. >the entry point in dom0 looks like: xen_acpi_processor_start xen_acpi_processor_power_init processor_cntl_xen_notify xen_ops.pm_ops xen_cx_notifier HYPERVISOR_dom0_op Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-10 14:56 UTC
AW: RE: RE: RE: [Xen-devel] No C-States any longer...
Some in-between notes, if someone is better in analyzing the code. There
is the following sequence
In drivers/scpi/processor_idle.c:
result = acpi_processor_get_power_info_cst(pr);
if (result == -ENODEV)
result = acpi_processor_get_power_info_fadt(pr);
if (result)
return result;
acpi_processor_get_power_info_default(pr);
On a working Intel machine, it will go through it like this:
- acpi_processor_get_power_info_cst, which returns 0
- acpi_processor_get_power_info_default
- later acpi_processor_power_verify will find some c-states
On my non-working AMD machine, it will go through like this:
- acpi_processor_get_power_info_cst, which returns -ENODEV
- acpi_processor_get_power_info_fadt, which also return -ENODEV
- this result is returned
The returned result -ENODEV is cascaded up to the call in
xen_acpi_processor_power_init, but there
nothing is checked or done.
I will now try to find the root cause (acpi_processor_get_power_info_cst
is to be checked next).
Carsten.
-----Ursprüngliche Nachricht-----
Von: Tian, Kevin [mailto:kevin.tian@intel.com]
Gesendet: Freitag, 10. Juni 2011 10:49
An: Carsten Schiers; xen-devel
Betreff: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de]
> Sent: Friday, June 10, 2011 3:09 AM
>
> Through some adding of printk I was able at least to verify that for
my> 3 core CPU AMD Athlon X3 400e
>
> - xen_px_notifier is called six times
> - Hypervisor is reporting XEN_PM_PX is called six times
> - Hypervisor is never reporting XEN_PM_CX to have been called
> - this is because xen_cx_notifier is never called.
> -> set_cx_pminfo is never called.
>
> What I will try to find out next is to check where xen_cx_notifier
> *should* be called. OS debugging is
> not realy my expertise, let''s see whether you first can give me a
hint
> or whether I am quicker to find
> it on my own.
>
the entry point in dom0 looks like:
xen_acpi_processor_start
xen_acpi_processor_power_init
processor_cntl_xen_notify
xen_ops.pm_ops
xen_cx_notifier
HYPERVISOR_dom0_op
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Friday, June 10, 2011 10:56 PM > > Some in-between notes, if someone is better in analyzing the code. There > is the following sequence > In drivers/scpi/processor_idle.c: > > result = acpi_processor_get_power_info_cst(pr); > > if (result == -ENODEV) > result = acpi_processor_get_power_info_fadt(pr); > > if (result) > return result; > > acpi_processor_get_power_info_default(pr); > > On a working Intel machine, it will go through it like this: > > - acpi_processor_get_power_info_cst, which returns 0 > - acpi_processor_get_power_info_default > - later acpi_processor_power_verify will find some c-statesthis is expected sequence> > On my non-working AMD machine, it will go through like this: > - acpi_processor_get_power_info_cst, which returns -ENODEV > - acpi_processor_get_power_info_fadt, which also return -ENODEV > - this result is returnedthough CST is optional, it''s weird that even FADT doesn''t contain valid Cx information. Could you compare with your working pvops dom0 version or compare with generic linux to see any difference? This parse logic should be generic for both Linux and Xen.> > The returned result -ENODEV is cascaded up to the call in > xen_acpi_processor_power_init, but there > nothing is checked or done. > > I will now try to find the root cause (acpi_processor_get_power_info_cst > is to be checked next).Anyway, you seems close to the root cause... Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2011-Jun-12 10:24 UTC
AW: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
There are some information in FACP (attached), there is no FADT. In order to test native Linux, I need some more days. Family & Barbecue have higher Prio ;o). Carsten. -----Ursprüngliche Nachricht----- Von: Tian, Kevin [mailto:kevin.tian@intel.com] Gesendet: Sonntag, 12. Juni 2011 10:57 An: Carsten Schiers; xen-devel Betreff: RE: RE: RE: RE: [Xen-devel] No C-States any longer...> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Friday, June 10, 2011 10:56 PM > > Some in-between notes, if someone is better in analyzing the code.There> is the following sequence > In drivers/scpi/processor_idle.c: > > result = acpi_processor_get_power_info_cst(pr); > > if (result == -ENODEV) > result = acpi_processor_get_power_info_fadt(pr); > > if (result) > return result; > > acpi_processor_get_power_info_default(pr); > > On a working Intel machine, it will go through it like this: > > - acpi_processor_get_power_info_cst, which returns 0 > - acpi_processor_get_power_info_default > - later acpi_processor_power_verify will find some c-statesthis is expected sequence> > On my non-working AMD machine, it will go through like this: > - acpi_processor_get_power_info_cst, which returns -ENODEV > - acpi_processor_get_power_info_fadt, which also return -ENODEV > - this result is returnedthough CST is optional, it''s weird that even FADT doesn''t contain valid Cx information. Could you compare with your working pvops dom0 version or compare with generic linux to see any difference? This parse logic should be generic for both Linux and Xen.> > The returned result -ENODEV is cascaded up to the call in > xen_acpi_processor_power_init, but there > nothing is checked or done. > > I will now try to find the root cause(acpi_processor_get_power_info_cst> is to be checked next).Anyway, you seems close to the root cause... Thanks Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2011-Jun-12 11:59 UTC
RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@schiers.de] > Sent: Sunday, June 12, 2011 6:24 PM > > There are some information in FACP (attached), there is no FADT.FADT is plain text table, not encoded with AML language. It should be always there. :-) Thanks Kevin> > In order to test native Linux, I need some more days. Family & Barbecue > have higher Prio ;o). > > Carsten. > > -----Ursprüngliche Nachricht----- > Von: Tian, Kevin [mailto:kevin.tian@intel.com] > Gesendet: Sonntag, 12. Juni 2011 10:57 > An: Carsten Schiers; xen-devel > Betreff: RE: RE: RE: RE: [Xen-devel] No C-States any longer... > > > From: Carsten Schiers [mailto:carsten@schiers.de] > > Sent: Friday, June 10, 2011 10:56 PM > > > > Some in-between notes, if someone is better in analyzing the code. > There > > is the following sequence > > In drivers/scpi/processor_idle.c: > > > > result = acpi_processor_get_power_info_cst(pr); > > > > if (result == -ENODEV) > > result = acpi_processor_get_power_info_fadt(pr); > > > > if (result) > > return result; > > > > acpi_processor_get_power_info_default(pr); > > > > On a working Intel machine, it will go through it like this: > > > > - acpi_processor_get_power_info_cst, which returns 0 > > - acpi_processor_get_power_info_default > > - later acpi_processor_power_verify will find some c-states > > this is expected sequence > > > > > On my non-working AMD machine, it will go through like this: > > - acpi_processor_get_power_info_cst, which returns -ENODEV > > - acpi_processor_get_power_info_fadt, which also return -ENODEV > > - this result is returned > > though CST is optional, it''s weird that even FADT doesn''t contain valid > Cx > information. Could you compare with your working pvops dom0 version or > compare with generic linux to see any difference? This parse logic > should > be generic for both Linux and Xen. > > > > > The returned result -ENODEV is cascaded up to the call in > > xen_acpi_processor_power_init, but there > > nothing is checked or done. > > > > I will now try to find the root cause > (acpi_processor_get_power_info_cst > > is to be checked next). > > Anyway, you seems close to the root cause... > Thanks > Kevin > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel