|
|
|
|
|
|
|
|
|
|
xen-users
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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|