|
|
|
|
|
|
|
|
|
|
xen-devel
RE: RE: RE: RE: RE: RE: [Xen-devel] No C-States any longer...
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> 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?
>
> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|