[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines
On Tue, 2011-12-20 at 16:51 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening > on some machines"): > > More specifically it seems to be > > 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32 > > branch. > > My script is still pulling from Jeremy's github. I see that the tree > on git.kernel.org has many new changesets so I'll switch back to that. > I guess I naively assumed that having established two trees Jeremy > might push to both of them... > > > I suspect that's a red-herring though since I bet the vmalloc fixes > > simply never got backported to this tree. > > Yes, it looks like they didn't. Looking at the tree the vmalloc_sync_all() in alloc_vm_area() is present and has been for ages. The upstream stuff I was thinking of was David Vrabel's work to make the sync unnecessary. The only difference in vmalloc_sync_all seems to be that 2.6.32 uses spin_lock_irqsave() while upstream uses just spin_lock() which doesn't seem likely to make a difference. The actual bug you are seeing is hitting the BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k)) towards the end of vmalloc_sync_one(). David, do you remember from when you were digging into this stuff what it actually means? I suppose we could backport the stuff to make vmalloc_sync_all unnecessary, but I guess there'd be no guarantee it would help since the root cause isn't really understood. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |