Description of problem: Xen-enabled Linux hangs with traceback. Version-Release number of selected component (if applicable): RHEL4.6 on top of RHEL5.1 (running 2.6.18-53.el5xen) How reproducible: I tried two times, both were eligible. Steps to Reproduce: 1. start installing RHEL4.6 via virt-manager on clear RHEL5.1 Xen domain0 2. mirror used was http://mirror.brq.redhat.com/rhel/RHEL-4/U6/AS/i386/tree/ 3. at some later point of installation it hangs and on virt. serial console I see this traceback: ------------------------------ kernel BUG at arch/i386/mm/hypervisor.c:196! invalid operand: 0000 [#1] SMP Modules linked in: dm_snapshot dm_mirror dm_zero dm_mod ext3 jbd msdos raid6 raid5 xor raid1 raid0 xenblk xennet sr_mod sd_mod scsi_mod cdrom loop nfs nfs_acl lockd sunrpc vfat fat cramfs vga16fb vgastate CPU: 0 EIP: 0061:[<c011548e>] Not tainted VLI EFLAGS: 00210082 (2.6.9-67.ELxenU) EIP is at xen_pgd_pin+0x46/0x54 eax: ffffffea ebx: d5d5cf20 ecx: 00000001 edx: 00000000 esi: 00007ff0 edi: d5d5cf90 ebp: d5d5cfbc esp: d5d5cf20 ds: 007b es: 007b ss: 0068 Process anaconda (pid: 429, threadinfo=d5d5c000 task=df29a6c0) Stack: 00000002 00063719 c7e13018 07e13000 000fc260 d91310c0 c0112ca2 07e13000 c7e13000 00000061 80000000 d9131104 c0112d36 c7e13000 d91310c0 00000000 c0269f6e d91310c0 deddc2c0 00000830 d246d2e0 c1400320 00040cc2 09f601c2 Call Trace: [<c0112ca2>] __pgd_pin+0x2d/0x41 [<c0112d36>] mm_pin+0x21/0x2e [<c0269f6e>] schedule+0x3a2/0x544 [<c0127423>] sys_rt_sigprocmask+0x97/0x14c [<c0105cd7>] sys_fork+0x16/0x1a [<c01073c6>] work_resched+0x5/0x25 Code: 00 75 0d a1 a0 e0 35 c0 8b 04 90 25 ff ff ff 7f 89 44 24 04 89 e3 b9 01 00 00 00 31 d2 be f0 7f 00 00 e8 b6 be fe ff 85 c0 79 08 <0f> 0b c4 00 7c 4e 27 c0 83 c4 10 5b 5e c3 56 53 83 ec 10 8b 54
Hm, that seems odd, I'm certain this is one of the combinations that's been well tested. I need some more details about the dom0; is it x86_64, or i386? When the RHEL-4 guest crashes, can you run "xm dmesg" and post the output here? Chris Lalancette
(In reply to comment #1) Hi Chris! > Hm, that seems odd, I'm certain this is one of the combinations that's been well > tested. I need some more details about the dom0; is it x86_64, or i386? When > the RHEL-4 guest crashes, can you run "xm dmesg" and post the output here? dom0 was x86_64 and the guest machine I was trying to install is i386, paravirtualized. Sorry I can not provide you with the output of "xm dmesg" at the moment because the machine is alredy being used under slightly different conditions. Best regards Jan Sarenik PS: I work as Lab Admin here in Brno office so I should be able to find some unused machine and test it again very soon. Will keep you updated.
Now, I am trying intallation of paravirtualized i386 RHEL4.6 on top of x86_64 RHEL 5.1 (with all up-to-date RHN fixes) and it does not work on two different host machines (one of them being Dell 1950 server, the other Xeon based IBM Blade). Not even such nice debugging options like on the first machine where I was able to see kernel messages in virtual serial console. I feel like giving in, but if you think there is any chance for me to be helpful in this case, let me know please. Best regards Jan Sarenik -- Lab Admin / System Admin, Red Hat Czech s.r.o., Purkynova 99, Brno
The collegue of mine told me that this particular configuration (putting RHEL4-32 on top of RHEL5-64) is tech-preview at the moment so now I know I am trying something which is well known for not working.
You should definitely give up. i386 PV on x86_64 dom0 is a combination known not to work in 5.1. There are some patches going in for 5.2 that should help this; I'm going to close this as a dup of the BZ we are using to track 32-on-64 support. Chris Lalancette *** This bug has been marked as a duplicate of 383211 ***