[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |