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 in_atomic():0, irqs_disabled():1 This bug was fixed upstream a year ago, see http://xenbits.xensource.com/xen-unstable.hg?rev/63263d715d43 Version-Release number of selected component (if applicable): kernel-2.6.18-91.el5.x86_64.rpm (and all prior RHEL5 xen/ia64 kernels) How reproducible: 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 Additional info: 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. Thanks, Chris Lalancette
I've uploaded a test kernel that contains this fix (along with several others) to this location: http://people.redhat.com/clalance/virttest Could the original reporter try out the test kernels there, and report back if it fixes the problem? Thanks, Chris Lalancette
Actually, while going back through BZ's, I've found that this is basically a dup of 288511. Closing it as such. Chris Lalancette *** This bug has been marked as a duplicate of bug 288511 ***