[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: RE: AW: Re: [Xen-devel] ACPI problem, was Xen BUG in mm / Xen 4.0.1 with 2.6.32.18/21 pvops Kernel?
>-----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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |