Red Hat Bugzilla – Bug 445221
BUG in slab.c on save/restore
Last modified: 2009-01-22 09:02:26 EST
Description of problem:
When saving/restoring a domU, it's possible to hit the following:
BUG: sleeping function called from invalid context at /.../slab.c:2901
This bug was fixed upstream a year ago, see
Version-Release number of selected component (if applicable):
(and all prior RHEL5 xen/ia64 kernels)
I couldn't reproduce this on RHEL with simple save/restore testing, but upstream
says it will only happen rarely and requires a loaded domU. Regardless, the
problem is well-understood and has been fixed upstream for a long time now, so
it would be good to see this fix preemptively in RHEL 5.x
I'll port the patch, test and post it to this bug
Created attachment 304696 [details]
backport of http://xenbits.xensource.com/xen-unstable.hg?rev/63263d715d43
This patch also removes a completely bogus call to xen_register_percpu_irq().
It's bogus because is_running_on_xen() is tested a few lines earlier and the
function returns if so. This showed up because the patch broke the compilation
of that call, which doesn't exist in the upstream sources. It looks like an
error (probably mine!) in the original port to fedora/rhel.
I tested this patch on kernel-2.6.18-92.el5.ia64.rpm dom0 and domU, boot plus
save/restore cycle. Everything checks out.
(Sorry about the typo in the comment 0; I accidentally typed x86_64 instead of ia64)
Created attachment 329074 [details]
ia64 slab.c corruption patch, v2
In order to get this patch to apply/build on the current 5.3 kernel, I had to munge it a bit. I think I did it right, but I'm definitely no ia64 expert, so if you could give the munged patch a quick once-over, that would be great.
I've uploaded a test kernel that contains this fix (along with several others)
to this location:
Could the original reporter try out the test kernels there, and report back if
it fixes the problem?
Actually, while going back through BZ's, I've found that this is basically a dup of 288511. Closing it as such.
*** This bug has been marked as a duplicate of bug 288511 ***