[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.