WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [Xen-users] 2.6.23 oops

Mark Williamson wrote:
>> I just realized I hadn't been reading your backtrace closely enough,
>> since it looks similar to the bug I'd been working on.  Turns out having
>> an xfs rootfs is what triggers your bug - I can repro it now, so I'll
>> see if I can work out what's going on.
>>
>> BTW, did last night's little patch help with the UP time issue?
>>     
>
> I've not had a chance to try it out yet...  I'll try and take a long.
>
> But I didn't entirely understand the semantic significance of the change?  
> Could you possibly elaborate?
>   

There was version drift in the register_vcpu_info hypercall arg
structure, and the version of the structure being used by the kernel was
smaller than the one that xen was expecting.

That meant that the mfn argument was OK, but the offset was being
corrupted, and so the vcpu_info structure could have been placed
anywhere, corrupting kernel memory.  For me it manifested as an oops,
but it could also have corrupted the timing parameters - or at the very
least, reading the time from the vcpu_info structure wouldn't work.

So I think there's a good chance this change would fix the UP problem. 
It doesn't hit in the same way in SMP because the per-cpu data area is
elsewhere, but it could still have caused havok.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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