Thank you very much, this will solve the issue. acpi_avaluate_object on
_PDC is now only called
twice.
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.
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.
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