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


Re: [Xen-devel] So I tried to use xentrace...

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] So I tried to use xentrace...
From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Date: Fri, 7 May 2010 16:16:34 -0500
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 07 May 2010 14:17:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BE47F26.50904@xxxxxxxx>
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: <4BDB4CCC.3080405@xxxxxxxx> <n2ode76405a1005071348m8f871b8cn49e50dff487943e6@xxxxxxxxxxxxxx> <4BE47F26.50904@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20100317)
Jeremy Fitzhardinge wrote:
(XEN) ----[ Xen-4.1-unstable  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e008:[<ffff82c4801215b3>] check_lock+0x1b/0x45

This suggests the problem is with misusing a lock in the wrong interrupt
context, rather than anything to do with sizes.
Except that, it works for me if I use -S 32, and doesn't if I use -S 512 (on my 2-core box, equivalent # of pages to -S 256 on your 4-core box). :-) Try it, I suspect it will work.

* It's a page fault with a null pointer, not a bugcheck. In a non-debug build, it will crash in spin_lock instead of check_lock. * The fault is in the MMU update hypercall; I believe done when xentrace tries to map garbage pages or invalid MFNs. * This is the exact bug we were getting in product, and the bounds-checking fixed it.

Hmm... the bounds checking should be working. The maximum index is meant to be 2048 (2 pages = 8k, / sizeof(uint32_t) = 2048), and the maximum index for you is 1088, well within the t_info size. Hmm...


Xen-devel mailing list

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