Description of problem: Well, the Xen kernel is broken somehow... May 13 16:18:41 rsc kernel: BUG: at kernel/fork.c:994 copy_process() May 13 16:18:41 rsc kernel: [<c1005d9a>] show_trace_log_lvl+0x1a/0x2f May 13 16:18:41 rsc kernel: [<c1006343>] show_trace+0x12/0x14 May 13 16:18:41 rsc kernel: [<c10063be>] dump_stack+0x16/0x18 May 13 16:18:41 rsc kernel: [<c101d044>] copy_process+0x195/0x1245 May 13 16:18:41 rsc kernel: [<c101e144>] do_fork+0x50/0x117 May 13 16:18:41 rsc kernel: [<c1003351>] kernel_thread+0x8e/0x96 May 13 16:18:41 rsc kernel: [<c102c701>] __call_usermodehelper+0x2d/0x46 May 13 16:18:41 rsc kernel: [<c102cd4f>] run_workqueue+0x89/0x145 May 13 16:18:41 rsc kernel: [<c102d711>] worker_thread+0xd5/0x102 May 13 16:18:41 rsc kernel: [<c102ff27>] kthread+0xb3/0xdc May 13 16:18:41 rsc kernel: [<c10058db>] kernel_thread_helper+0x7/0x10 May 13 16:18:41 rsc kernel: ======================= Version-Release number of selected component (if applicable): kernel-xen-2.6.20-2925.5.fc7 How reproducible: Everytime for me. Steps to Reproduce: 1. Install the virtualization stuff using pirut 2. Change boot order 3. Boot system Expected results: Fixed... ;-)
The -2925.5.fc7 has known data corruptions bugs. Please update to latest rawhide & retest. The current latest kernel version is kernel-xen-2.6.20-2925.8.fc7
I can reproduce this with 2.6.20-2925.7.fc7 32 bit kernel (not 64 bit), so I had assumed it was related to the 32 bit upcall problem which Stephen Tweedie fixed. Will test again with latest kernel.
I don't see this happening on the .8. kernel.
I can't see this problem in 2.6.20-2925.8 no longer, too.