Hide Forgot
Description of problem: I have a host running # uname -r 2.6.20-2925.7.fc7xen # uname -m x86_64 I attempt to provision a 32-bit host # virt-install --name fc7x32 --location http://reducto.boston.redhat.com/pungi/dev16.0/7/Fedora/i386/os/ --ram 500 --file /var/lib/xen/images/fc7x32.img --file-size 4 --nographics --paravirt And it panics with Oops: 0000 [#1] SMP last sysfs file: Modules linked in: xenblk xennet iscsi_tcp libiscsi scsi_transport_iscsi sr_mod sd_mod scsi_mod cdrom ipv6 ext2 ext3 mbcache jbd squashfs pcspkr loop nfs nfs_acl lockd sunrpc vfat fat cramfs CPU: 0 EIP: 0061:[<e0965928>] Not tainted VLI EFLAGS: 00010887 (2.6.20-2925.8.fc7xen #1) EIP is at blkif_int+0x5a/0x18c [xenblk] eax: 18009c00 ebx: deea2000 ecx: c12c02e0 edx: ca000100 esi: 00000000 edi: dee870ac ebp: c135ffc8 esp: c135ff9c ds: 007b es: 007b ss: 0069 Process swapper (pid: 0, ti=c135f000 task=c12c02e0 task.ti=c130a000) Stack: 00000000 c135ffc8 c10385d2 00000001 00000002 00000001 ca000100 c12fd738 dee8f660 00000000 00000000 c135ffe0 c1048ee9 00000106 c12fd700 00000106 dee8f660 c135fff8 c104a2e4 c12fd728 c130af18 00000106 c104a24a c130af34 Call Trace: [<c1005d9e>] show_trace_log_lvl+0x1a/0x2f [<c1005e4e>] show_stack_log_lvl+0x9b/0xa3 [<c1005fea>] show_registers+0x194/0x26a [<c10061f1>] die+0x131/0x246 [<c11f9831>] do_page_fault+0xafc/0xc80 [<c11f7b25>] error_code+0x35/0x3c [<c1048ee9>] handle_IRQ_event+0x1a/0x4a [<c104a2e4>] handle_level_irq+0x9a/0xea [<c10070a8>] do_IRQ+0xc6/0xee ======================= Code: e8 66 90 8b 43 20 89 45 e0 e9 ed 00 00 00 8b 43 24 31 f6 48 23 45 e0 6b c0 6c 8d 78 40 03 7b 28 8b 17 69 c2 9c 00 00 00 89 55 ec <8b> 94 18 c8 00 00 00 8d 44 18 5c 89 45 f0 89 55 dc eb 11 8b 55 EIP: [<e0965928>] blkif_int+0x5a/0x18c [xenblk] SS:ESP 0069:c135ff9c <0>Kernel panic - not syncing: Fatal exception in interrupt After this there are also 2 dodgy looking messages in HV logs: # xm dmesg | tail -2 (XEN) grant_table.c:230:d0 Bad ref (2688768). (XEN) grant_table.c:230:d0 Bad ref (2688768). Version-Release number of selected component (if applicable): kernel-xen-2.6.20-2925.7.fc7 xen-3.1.0-0.rc7.1.fc7 How reproducible: Always Steps to Reproduce: 1. Run the virt-install command shown above 2. Watch it boot... 3. Actual results: Crashes during boot Expected results: Additional info:
Created attachment 154838 [details] Kernel boot logs
I'm guessing this is a result of our kernel-xen still being based on the 3.0.4 patches. There was this changeset in 3.1.0 tree which I'm sure would be a pre-requisite for 32-on-64 to work: changeset: 13573:c9ac0bace498 user: kfraser@localhost.localdomain date: Wed Jan 24 10:38:17 2007 +0000 files: linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c linux-2.6-xen-sparse/drivers/xen/blkback/common.h linux-2.6-xen-sparse/drivers/xen/blkback/interface.c linux-2.6-xen-sparse/drivers/xen/blkback/xenbus.c linux-2. 6-xen-sparse/drivers/xen/blktap/blktap.c linux-2.6-xen-sparse/drivers/xen/blktap/common.h linux-2.6-xen-sparse/drivers/xen/blktap/interface.c linux-2.6-xen-sparse/drivers/xen/blktap/xenbus.c linux-2.6-xen-sparse/include/xen/b lkif.h xen/include/public/io/blkif.h description: bimodal blkback: Support multiple ring protocols. This is needed for 32-on-64 support. Right now there are three protocols: native, x86_32 and x86_64. If needed it can be extended. Interface changes (io/blkif.h) * Define the x86_32 and x86_64 structs additionally to the native version. * Add helper functions to convert them requests to native. Backend changes: * Look at the "protocol" name of the frontend and switch ring handling accordingly. If the protocol node isn't present it assumes native protocol. * As the request struct is copied anyway before being processed (for security reasons) it is converted to native at that point so most backend code doesn't need to know what the frontend speaks. * In case of blktap this is completely transparent to userspace, the kernel/userspace ring is always native no matter what the frontend speaks. Signed-off-by: Gerd Hoffmann <kraxel@suse.de> There's a couple of other changesets too, so I think we should wait until kernel-xen is updated to 3.0.5 before investigating this further.
change QA contact
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This is addressed in F8.