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/
Home Products Support Community News


AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Ke

To: "Carsten Schiers" <carsten@xxxxxxxxxx>
Subject: AW: Re: [Xen-devel] Xen BUG in mm / Xen 4.0.1 with pvops Kernel?
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 10 Sep 2010 09:45:00 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 10 Sep 2010 01:46:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <H00000670008304a.1284057636.uhura.space.zz@MHS>
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: <H000006700083044.1284056830.uhura.space.zz@MHS> <H00000670008304a.1284057636.uhura.space.zz@MHS>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 09.09.10 at 20:40, "Carsten Schiers" <carsten@xxxxxxxxxx> wrote:
> OK, here are the three SSDT's that I seem to have. BR, Carsten.

SSDT1.dsl seems to be the bad one: While the SSDT package defined
at the top is reasonable (having invalid entries only for CPUs 2 and
up), the CSDT package is bogus, and gets referenced later in the
same file in \_PR.P001._OSC:

            If (LAnd (LAnd (LEqual (And (PDC0, 0x18), 0x18), LEqual (
                CTB0, Zero)), LEqual (And (CFGD, 0x20), 0x20)))
                Or (CTB0, 0x01, CTB0)
                OperationRegion (CT00, SystemMemory, DerefOf (Index (CSDT, 
0x01)), DerefOf (Index (CSDT, 0x02
                Load (CT00, HC0)

Hence, at least if the condition is true (not sure how the ACPI
interpreter works wrt mapping memory in the body of false
conditionals) a memory range of 0x80000000 bytes at address
0x80000000 will be attempted to be created and accessed,
no matter how much memory the system has (and the
variable the initialize with the memory access doesn't appear
to be used at all). I'm really surprised you (they) get away
with this on a native kernel... Did you try to compare control
flow of Xen and native kernels?


Xen-devel mailing list

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