On 09/14/2010 10:37 PM, Jiang, Yunhong wrote:
> 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.
BTW, I got around to applying this yesterday, so it should be in
xen/stable-2.6.32.x soon (it's currently in xen/next-2.6.32).
J
> 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