[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 notseen 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 thesame 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 Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |