>-----Original Message-----
>From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
>Sent: Wednesday, September 15, 2010 3:23 PM
>To: Wei, Gang; jeremy; Wang, Winston L; Jiang, Yunhong
>Cc: JBeulich; xen-devel
>Subject: AW: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
>4.0.1
>with 2.6.32.18/21 pvops Kernel?
>
>Thank you very much, this will solve the issue. acpi_avaluate_object on
>_PDC is now only called
>twice.
Glad to knows about this.
>
>For the records: we spoke about an Asrock P5B-DE BIOS 1.10 board
>equipped with an Intel E2200
>and 4GB of RAM. The problem will not occur, if Speedstep is disabled, or
>only 2 GB RAM is used.
Yes, 2GB RAM is ok because the 0x80000000 is above 2G, thus hypervisor think it
is MMIO in such situation and avoid such situation.
>
>As I am not such an expert (although through this experience, I now know
>much more about ACPI),
>can we now assume that the BIOS is ok? It's because I mailed the Asrock
>guys already and either
>need to give them the latest info, or I would explain them everything is
>settled.
I think BIOS is ok. Sorry for the issue caused.
Thanks
--jyh
>
>BR & Thanks again,
>Carsten.
>
>
>-----Ursprüngliche Nachricht-----
>Von: Jiang, Yunhong [mailto:yunhong.jiang@xxxxxxxxx]
>Gesendet: Mittwoch, 15. September 2010 07:37
>An: Wang, Winston L; Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers
>Cc: JBeulich; xen-devel
>Betreff: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
>4.0.1 with 2.6.32.18/21 pvops Kernel?
>
>Jimmy and I checked the log and the SSDT table, since it is caused by a
>workaround in Xen PVops dom0. Currently PVOPS dom0 will try to get all
>CPU's information in the system, no matter it is populated or not, while
>native Linux will get the CPU information only if it is enabled. During
>this process, following SSDT code cause trouble:
>
>The followed SSDT code try to load region
> OperationRegion (GV03, SystemMemory, DerefOf (Index
>(SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
> )))
> Load (GV03, HI3)
>
>While the region is defined as:
> Name (SSDT, Package (0x18)
> {
> "CPU0IST ",
> 0xBBFB00B0,
> 0x00000235,
> "CPU1IST ",
> 0xBBFB02F0,
> 0x00000235,
> "CPU2IST ",
> 0x80000000,
> 0x80000000,
> "CPU3IST ",
> 0x80000000,
> 0x80000000,
> "CPU4IST ",
> 0x80000000,
> 0x80000000,
>That seems try to load to 0x80000000.
>
>Can you please try to apply the attached patch to see if it has any
>help? This patch should enable dom0 to only scan enabled CPUs.
>
>Thanks
>--jyh
>
>
>>-----Original Message-----
>>From: Wang, Winston L
>>Sent: Wednesday, September 15, 2010 10:03 AM
>>To: Wei, Gang; Jeremy Fitzhardinge; Carsten Schiers
>>Cc: JBeulich; xen-devel; Jiang, Yunhong
>>Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen
>>4.0.1 with
>>2.6.32.18/21 pvops Kernel?
>>
>>I am forward this to Jimmy, he is currently working on Xen acpi4.0
>support.
>>I know ACPI 4.0 on native 2.6.32 is buggy besides possible BIOS
>>firmware bug, would you check if native has the similar issue? if you
>>can provide acpi error dump, that will be helpful.
>>By the way, what platform are you using?
>>
>>Regards,
>>
>>Winston,
>>
>>> -----Original Message-----
>>> From: Yu, Ke
>>> Sent: Tuesday, September 14, 2010 6:20 PM
>>> To: Jeremy Fitzhardinge; Carsten Schiers; Wang, Winston L
>>> Cc: JBeulich; xen-devel; Jiang, Yunhong
>>> Subject: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm /
>>> Xen
>>> 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>>
>>> CC Winston, who has is working on the Xen ACPI stuff.
>>>
>>> Regards
>>> Ke
>>>
>>> > -----Original Message-----
>>> > From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>>> > Sent: Wednesday, September 15, 2010 6:05 AM
>>> > To: Carsten Schiers
>>> > Cc: JBeulich; xen-devel; Yu, Ke; Jiang, Yunhong
>>> > Subject: Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm /
>>> Xen
>>> > 4.0.1 with 2.6.32.18/21 pvops Kernel?
>>> >
>>> > On 09/14/2010 02:19 PM, Carsten Schiers wrote:
>>> > >> But in any case - the root cause is broken firmware.
>>> > > Getting deeper into it. The faulty entries seems not to be the
>>> CPUxCST,
>>> > > but CPUxIST
>>> > > for CPU2 and up. For a reason I don't know, native booting the
>>> kernel
>>> > > doesn't run
>>> > > into this issue. I have managed to get a veeeeery detailed ACPI
>>> debug
>>> > > output now
>>> > > from the Xen/Dom0 kernel, will try to do the same with native
>>> booted
>>> > > Kernel tomorrow.
>>> > >
>>> > > I know already that the natively booting kernel will also run
>>> through 4
>>> > > CPUs, even
>>> > > though my CPU has only 2 cores. So it must be something
>different.
>>> There
>>> > > is special
>>> > > code in the acpi driver section for xen in the pvops kernel...
>>> > >
>>> > > Jeremy, did you do it? Who could possibly help? I am not a real
>>> > > specialist...
>>> > >
>>> > > Did not attached the log, in case anybody is interested...it's
>31MB.
>>> >
>>> > I'm not really an expert on ACPI at all. I've cc:d some of the
>>> > Intel folks who've been very helpful in contributing ACPI changes.
>>> >
>>> > J
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home