[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] 100% reliable Oops on xen 4.0.1
Just to close the loop over here. This is an audit bug, not a xen bug. https://www.redhat.com/archives/linux-audit/2012-August/msg00018.html Cheers, peter On Tue, Aug 14, 2012 at 9:26 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> On 14.08.12 at 18:16, Peter Moody <pmoody@xxxxxxxxxx> wrote: >> On Tue, Aug 14, 2012 at 9:09 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote: >> >>> From the above as well as based on you indicating that the >>> traces are highly variable between instances, I'd suppose >>> this is memory corruption of some sort, which can easily be >>> hidden by all sorts of factors. >>> >>> Until you can find a pattern, I don't think there can be done >>> much by anyone not having an affected system available for >>> debugging. >> >> So I have such a system :). > > That's what I implied. > >> Are there any pointers or tips you can give me to help me track down >> the root cause? I realize that's a broad question, and a perfectly >> justifiable answer is "read the memory management chapter of >> understanding linux device drivers" but at this point basically any >> advice you can give me is appreciated (and will most likely get me >> closer to the solution). > > As said, figuring out a pattern in the crashes would likely help > placing debug prints, breakpoints, or anything similar to aid > detecting the presumed corruption earlier. Without a pattern, > there's regretfully not much I can suggest. > > Jan > -- Peter Moody Google 1.650.253.7306 Security Engineer pgp:0xC3410038 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |