WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with

To: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
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?
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 15 Sep 2010 10:01:53 -0700
Cc: Carsten Schiers <carsten@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wang, Winston L" <winston.l.wang@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, JBeulich <JBeulich@xxxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 10:02:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <789F9655DD1B8F43B48D77C5D30659732A3654AF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <H000006700083c21.1284499172.uhura.space.zz@MHS> <4C8FF18F.9010607@xxxxxxxx> <33AB447FBD802F4E932063B962385B352A721A4A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <54B2EB610B7F1340BB6A0D4CA04A4F10B3A2470C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <789F9655DD1B8F43B48D77C5D30659732A3654AF@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 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

<Prev in Thread] Current Thread [Next in Thread>