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-users] DomU Oopsing on xen-3.0-testing changeset 8259

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-users] DomU Oopsing on xen-3.0-testing changeset 8259
From: Charles Duffy <cduffy@xxxxxxxxxxx>
Date: Tue, 27 Dec 2005 12:39:55 -0600
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 27 Dec 2005 18:44:19 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D409EB8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D409EB8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (Windows/20051025)
Ian Pratt wrote:
One of my DomUs is sporadically oopsing, roughly once per day. This was first observed on a pre-3.0-release changeset; after upgrading to changeset 8259 on the xen-3.0-testing branch (after the release), it still occurs.

There's just not very much to go on picking appart this oops.

It looks like things are blowing up deep in the bowels of the kernel
while running delivering a signal to some java app. I've certainly not
seen anything like this, depsite doing quite a bit of java testing.
Please can you give more details of what jvm you're using, and what the
application is doing.

Better, can you try and recreate a way of repro'ing the bug on demand?
I'm not sure where to start at wrt causing it on-demand. The JVM is the x86_64 version of BEA's JRockit 1.5.0_03-b07 (R25.2.0-28). The application is a long-running Tomcat instance; determining exactly what it's doing at that time would probably require a level of logging so in-depth as to make the application unusable -- and since it's under frequent use for (sometimes) days at a time between crashes, I'm not sure that there *is* any single user-visible operation which immediately triggers the issue -- if there were, I hope the users would have mentioned as much to me.

(There are actually two such long-running Tomcat instances running different versions of the same application simultaneously).
This effectively kills the instance when it occurs -- worse, the instance in question *stays* down even though panic=5 is specified as an extra parameter to be passed to the DomU kernel.

This is probably easier to fix -- I seem to recall a patch going into
the merge tree recently that made the panic behaviour on x86_64 xen the
same as native.
That would be good. Is the merge tree the one that's being used for the 2.6.14 kernel support, or is that something different? What's its name in mercurial, so I can hunt for the changeset?
The text of the oops is attached, as are my kernel configs (which are a touch nonstandard).

Hmm, can you reproduce with one of our configs? (Or at least post the
minimal diff from ours).
Maybe. I'll have to try it when I can find time to make my (initramfs-based, no-modules) boot sequence work with the stock config -- I vaguely remember there being some reason it didn't.

Xen-users mailing list

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