I''m trying to install a RHEL 5 32-bit guest on a F7 64-bit host.
It seems to crash as its booting anaconda.
Versions:
Compiled against library: libvir 0.3.1
Using library: libvir 0.3.1
Using API: Xen 3.0.1
Running hypervisor: Xen 3.1.0
Is the version mismatch between the API and hypervisor versions a problem?
Serial Console crash:
Oops: 0000 [#1]
SMP
last sysfs file: /class/graphics/fb0/name
Modules linked in: xenblk xennet iscsi_tcp libiscsi scsi_transport_iscsi
sr_mod sd_mod scsi_mod ide_cd cdrom ipv6 squashfs
pcspkr loop nfs nfs_acl fscache lockd sunrpc vfat fat cramfs
CPU: 0
EIP: 0061:[<ee2febc3>] Not tainted VLI
EFLAGS: 00010046 (2.6.18-8.el5xen #1)
EIP is at blkif_int+0xca/0x16b [xenblk]
eax: 00000000 ebx: c0e5e000 ecx: c07e5e20 edx: 00000000
esi: 00000000 edi: ca000100 ebp: c0e3f0ac esp: c071bfa4
ds: 007b es: 007b ss: 0069
Process init (pid: 235, ti=c071b000 task=c07e2550 task.ti=c07e5000)
Stack: 00000000 00000001 00000002 00000000 d8e67c7c c0f9a720 00000000
00000000
00000108 c043ec9b c07e5e20 c06bb828 c06bb800 00000108 fffffffe
c043ed58
c07e5e20 c0f9a720 c07e5df0 00000108 c07e5e20 fffffffe c040672b
Call Trace:
[<c043ec9b>] handle_IRQ_event+0x27/0x51
[<c043ed58>] __do_IRQ+0x93/0xe8
[<c040672b>] do_IRQ+0x93/0xae
[<c053a045>] evtchn_do_upcall+0x64/0x9b
[<c0404ec5>] hypervisor_callback+0x3d/0x48
[<c0539994>] force_evtchn_callback+0xa/0xc
[<c041b8ce>] release_console_sem+0x18c/0x1c6
[<c0524d20>] do_con_write+0x64/0x149d
[<c04b0689>] inode_has_perm+0x54/0x5c
[<c04b0787>] task_has_capability+0x50/0x58
[<c0526180>] con_put_char+0x27/0x2a
[<c051bc4d>] opost+0x17c/0x192
[<c051c36c>] write_chan+0x1ed/0x294
[<c0415e6c>] default_wake_function+0x0/0xc
[<c0519f23>] tty_write+0x147/0x1d8
[<c051c17f>] write_chan+0x0/0x294
[<c06e5e40>] af_unix_init+0x0/0x59
[<c0519ddc>] tty_write+0x0/0x1d8
[<c046271b>] vfs_write+0xa1/0x143
[<c0462d0d>] sys_write+0x3c/0x63
[<c0404cff>] syscall_call+0x7/0xb
======================Code: 00 c7 80 84 00 00 00 00 00 00 00 c7 80 e8 00 00 00
00 00 00 00 89 bb
fc 13 00 00 80 7d 08 01 77 35 8b 04 24 31 d2 66
83 7d 0a 00 <8b> 48 2c 0f 94 c2 e8 7a 99 1c d2 85 c0 74 08 0f 0b ac 02 08
f3
EIP: [<ee2febc3>] blkif_int+0xca/0x16b [xenblk] SS:ESP 0069:c071bfa4
<0>Kernel panic - not syncing: Fatal exception in interrupt
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Jason Solan
2007-Aug-27 14:48 UTC
Re: [Xen-users] 32bit on 64-bit causes guest Kernel oops
FYI, I''ve not had any success in getting 32 on 64 working with Fedora 7. I gave up assuming that its not going to be in the F7 release, even though its stated as using xen version 3.1. There was an email on the fedora-xen mailing list back in June or early July stating that there was a kernel update coming soon to fix the issue. I''ve since applied 2 kernel updates and still get a kernel panic when trying to boot a 32 bit PV guest. 32-bit HVM''s seem to work fine though. If anyone else has had a success story using the F7 packages please feel free to correct me. On Mon, 2007-08-27 at 10:05 -0400, Nathan Widmyer wrote:> I''m trying to install a RHEL 5 32-bit guest on a F7 64-bit host. > It seems to crash as its booting anaconda. > > Versions: > Compiled against library: libvir 0.3.1 > Using library: libvir 0.3.1 > Using API: Xen 3.0.1 > Running hypervisor: Xen 3.1.0 > > Is the version mismatch between the API and hypervisor versions a > problem? > > Serial Console crash: > Oops: 0000 [#1] > SMP > last sysfs file: /class/graphics/fb0/name > Modules linked in: xenblk xennet iscsi_tcp libiscsi > scsi_transport_iscsi sr_mod sd_mod scsi_mod ide_cd cdrom ipv6 squashfs > pcspkr loop nfs nfs_acl fscache lockd sunrpc vfat fat cramfs > CPU: 0 > EIP: 0061:[<ee2febc3>] Not tainted VLI > EFLAGS: 00010046 (2.6.18-8.el5xen #1) > EIP is at blkif_int+0xca/0x16b [xenblk] > eax: 00000000 ebx: c0e5e000 ecx: c07e5e20 edx: 00000000 > esi: 00000000 edi: ca000100 ebp: c0e3f0ac esp: c071bfa4 > ds: 007b es: 007b ss: 0069 > Process init (pid: 235, ti=c071b000 task=c07e2550 task.ti=c07e5000) > Stack: 00000000 00000001 00000002 00000000 d8e67c7c c0f9a720 00000000 > 00000000 > 00000108 c043ec9b c07e5e20 c06bb828 c06bb800 00000108 fffffffe > c043ed58 > c07e5e20 c0f9a720 c07e5df0 00000108 c07e5e20 fffffffe c040672b > Call Trace: > [<c043ec9b>] handle_IRQ_event+0x27/0x51 > [<c043ed58>] __do_IRQ+0x93/0xe8 > [<c040672b>] do_IRQ+0x93/0xae > [<c053a045>] evtchn_do_upcall+0x64/0x9b > [<c0404ec5>] hypervisor_callback+0x3d/0x48 > [<c0539994>] force_evtchn_callback+0xa/0xc > [<c041b8ce>] release_console_sem+0x18c/0x1c6 > [<c0524d20>] do_con_write+0x64/0x149d > [<c04b0689>] inode_has_perm+0x54/0x5c > [<c04b0787>] task_has_capability+0x50/0x58 > [<c0526180>] con_put_char+0x27/0x2a > [<c051bc4d>] opost+0x17c/0x192 > [<c051c36c>] write_chan+0x1ed/0x294 > [<c0415e6c>] default_wake_function+0x0/0xc > [<c0519f23>] tty_write+0x147/0x1d8 > [<c051c17f>] write_chan+0x0/0x294 > [<c06e5e40>] af_unix_init+0x0/0x59 > [<c0519ddc>] tty_write+0x0/0x1d8 > [<c046271b>] vfs_write+0xa1/0x143 > [<c0462d0d>] sys_write+0x3c/0x63 > [<c0404cff>] syscall_call+0x7/0xb > ======================> Code: 00 c7 80 84 00 00 00 00 00 00 00 c7 80 e8 00 00 00 00 00 00 00 > 89 bb fc 13 00 00 80 7d 08 01 77 35 8b 04 24 31 d2 66 > 83 7d 0a 00 <8b> 48 2c 0f 94 c2 e8 7a 99 1c d2 85 c0 74 08 0f 0b ac > 02 08 f3 > EIP: [<ee2febc3>] blkif_int+0xca/0x16b [xenblk] SS:ESP 0069:c071bfa4 > <0>Kernel panic - not syncing: Fatal exception in interrupt > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nathan Widmyer
2007-Aug-27 15:21 UTC
Re: [Xen-users] 32bit on 64-bit causes guest Kernel oops
I kind of assumed this Xen host server from somebody so I''m not sure how exactly it was setup. I do know that it had the standard Xen 3.0.3 at install-time and apparently the RPM''s were updated: [root@machine ~]# rpm -qa | grep xen xen-libs-3.1.0-2.fc7 kernel-xen-2.6.20-2925.13.fc7 <--- running host kernel kernel-xen-2.6.20-2931.fc7 xen-3.1.0-2.fc7 The Xen hypervisor boot shows Xen 3.1.0-rc7. I''m going to try and FV the install then PV the install later. I''m thinking it''s more of a problem with anaconda than with Xen because the kernel boots and operates somewhat. On 8/27/07, Jason Solan <jsolan@jsolan.homelinux.com> wrote:> > FYI, I''ve not had any success in getting 32 on 64 working with Fedora 7. > I gave up assuming that its not going to be in the F7 release, even > though its stated as using xen version 3.1. There was an email on the > fedora-xen mailing list back in June or early July stating that there > was a kernel update coming soon to fix the issue. I''ve since applied 2 > kernel updates and still get a kernel panic when trying to boot a 32 bit > PV guest. > > 32-bit HVM''s seem to work fine though. > > If anyone else has had a success story using the F7 packages please feel > free to correct me. > > > On Mon, 2007-08-27 at 10:05 -0400, Nathan Widmyer wrote: > > I''m trying to install a RHEL 5 32-bit guest on a F7 64-bit host. > > It seems to crash as its booting anaconda. > > > > Versions: > > Compiled against library: libvir 0.3.1 > > Using library: libvir 0.3.1 > > Using API: Xen 3.0.1 > > Running hypervisor: Xen 3.1.0 > > > > Is the version mismatch between the API and hypervisor versions a > > problem? > > > > Serial Console crash: > > Oops: 0000 [#1] > > SMP > > last sysfs file: /class/graphics/fb0/name > > Modules linked in: xenblk xennet iscsi_tcp libiscsi > > scsi_transport_iscsi sr_mod sd_mod scsi_mod ide_cd cdrom ipv6 squashfs > > pcspkr loop nfs nfs_acl fscache lockd sunrpc vfat fat cramfs > > CPU: 0 > > EIP: 0061:[<ee2febc3>] Not tainted VLI > > EFLAGS: 00010046 (2.6.18-8.el5xen #1) > > EIP is at blkif_int+0xca/0x16b [xenblk] > > eax: 00000000 ebx: c0e5e000 ecx: c07e5e20 edx: 00000000 > > esi: 00000000 edi: ca000100 ebp: c0e3f0ac esp: c071bfa4 > > ds: 007b es: 007b ss: 0069 > > Process init (pid: 235, ti=c071b000 task=c07e2550 task.ti=c07e5000) > > Stack: 00000000 00000001 00000002 00000000 d8e67c7c c0f9a720 00000000 > > 00000000 > > 00000108 c043ec9b c07e5e20 c06bb828 c06bb800 00000108 fffffffe > > c043ed58 > > c07e5e20 c0f9a720 c07e5df0 00000108 c07e5e20 fffffffe c040672b > > Call Trace: > > [<c043ec9b>] handle_IRQ_event+0x27/0x51 > > [<c043ed58>] __do_IRQ+0x93/0xe8 > > [<c040672b>] do_IRQ+0x93/0xae > > [<c053a045>] evtchn_do_upcall+0x64/0x9b > > [<c0404ec5>] hypervisor_callback+0x3d/0x48 > > [<c0539994>] force_evtchn_callback+0xa/0xc > > [<c041b8ce>] release_console_sem+0x18c/0x1c6 > > [<c0524d20>] do_con_write+0x64/0x149d > > [<c04b0689>] inode_has_perm+0x54/0x5c > > [<c04b0787>] task_has_capability+0x50/0x58 > > [<c0526180>] con_put_char+0x27/0x2a > > [<c051bc4d>] opost+0x17c/0x192 > > [<c051c36c>] write_chan+0x1ed/0x294 > > [<c0415e6c>] default_wake_function+0x0/0xc > > [<c0519f23>] tty_write+0x147/0x1d8 > > [<c051c17f>] write_chan+0x0/0x294 > > [<c06e5e40>] af_unix_init+0x0/0x59 > > [<c0519ddc>] tty_write+0x0/0x1d8 > > [<c046271b>] vfs_write+0xa1/0x143 > > [<c0462d0d>] sys_write+0x3c/0x63 > > [<c0404cff>] syscall_call+0x7/0xb > > ======================> > Code: 00 c7 80 84 00 00 00 00 00 00 00 c7 80 e8 00 00 00 00 00 00 00 > > 89 bb fc 13 00 00 80 7d 08 01 77 35 8b 04 24 31 d2 66 > > 83 7d 0a 00 <8b> 48 2c 0f 94 c2 e8 7a 99 1c d2 85 c0 74 08 0f 0b ac > > 02 08 f3 > > EIP: [<ee2febc3>] blkif_int+0xca/0x16b [xenblk] SS:ESP 0069:c071bfa4 > > <0>Kernel panic - not syncing: Fatal exception in interrupt > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Bastian Blank
2007-Aug-29 10:08 UTC
Re: [Xen-users] 32bit on 64-bit causes guest Kernel oops
On Mon, Aug 27, 2007 at 10:05:01AM -0400, Nathan Widmyer wrote:> Is the version mismatch between the API and hypervisor versions a problem?No. But a missmatch in the blkback-blkfront-interface. The protocol is not compatible between x86_32 and x86_64 and the ability to handle both was added in blkbak for the 3.1 kernel. The fedora kernel is based on 3.0.4. Bastian -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users