Re: [Xen-users] DomU Oopsing on xen-3.0-testing changeset 8259
Ian Pratt wrote:
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.
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?
(There are actually two such long-running Tomcat instances running
different versions of the same application simultaneously).
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?
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.
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.
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).
Xen-users mailing list