Hide Forgot
Description of problem: The kernel/drivers/xen/blktap/blktap.ko module does not build on ia64: drivers/xen/blktap/blktapmain.c: In function 'fast_flush_area': drivers/xen/blktap/blktapmain.c:902: error: implicit declaration of function 'create_lookup_pte_addr' Version-Release number of selected component (if applicable): kernel-xen-2.6.18-1.2724.fc6.ia64 blktap has been disabled on ia64 for now: $ grep TAP configs/*xen* configs/config-xen-generic:CONFIG_XEN_BLKDEV_TAP=m configs/config-xen-ia64:# CONFIG_XEN_BLKDEV_TAP is not set
Created attachment 137553 [details] blktap compile fix for ia64
Here is a patch that gets things building. It's a bit of a hack since it copies create_lookup_pte_addr into ia64 specific source files. With this patch the thing builds, and boots. However each of the blkback, netback and blktap fail with the same error. Basically none of the backend drivers are working on ia64, they each fail in balloon_alloc_empty_page_range() due to failed __get_free_pages() attempt with large order.
Yes; the backend allocating issue is already being tracked as bug 202971.
OK, in that case we could apply the blktap fix to get things working to a point that they can be debugged.
Assigning to agriffis.
GNTMAP_application_map does not support Xen/IA64. the blktap uses this function, so it does not run. even if it fixes compilation.
This bug is still in kernel-xen-2.6.18-1.2784.fc6
in kernel-2.6.18-1.2728.el5
Reopening, because the el5 kernel is not a fix for a devel bug!
Unfortunately the compile fix for blktap on ia64 isn't nearly enough. Sure it allows the module to build, and that's great so that it doesn't need to be disabled. However the requisite support isn't in the ia64 hypervisor yet. See http://lists.xensource.com/archives/html/xen-ia64-devel/2006-10/msg00206.html Hopefully this will be fixed upstream in time for RHEL5 release. Unfortunately it didn't make FC6
Isaku Yamahata (Fujitsu) finished this work. It is now in xen-unstable: http://xenbits.xensource.com/xen-unstable.hg?cs=862aca401601 http://xenbits.xensource.com/xen-unstable.hg?cs=3cc7e419b949 http://xenbits.xensource.com/xen-unstable.hg?cs=f56b7ade7068 Unfortunately blktap has diverged somewhat between xen-unstable.hg and RHEL5, with unique fixes in each that haven't yet been merged to the other. They'll undoubtedly converge in due course, but at the moment this means a little porting work for the above patches to apply to RHEL5. I'll update this bug with those soon, hopefully.
Created attachment 141558 [details] blktap/ia64 patches ported to rhel5
Note that the blktap patches also require this change in kernel-2.6.18-ia64-xen.config -# CONFIG_XEN_BLKDEV_TAP is not set +CONFIG_XEN_BLKDEV_TAP=m
Note that attachment 141558 [details] should obsolete attachment 137553 [details] but I didn't have permissions to do that.
Patches cleanly atop kernel 2747, along with the first two patches in bug 210637 and the unaligned access patch in bug 212645. Appears to require user-space xen tools changes as well (patches also in 210637), building that momentarily...
Okay, user-space bits updated too... However, switching over a loop guest to use blktap, as well as starting a new install using virt-install, puts the system in a very bad state. Just after loading the blkdev module, things go haywire. ----8<---- [...] Loading ehci-hcd.ko module Loading jbd.ko module Loading ext3.ko module Loading xenblk.ko module Registering block device major 202 xvda:Creating root device. <indefinite hang> ----8<---- If one tries a 'ps ax', it hangs indefinitely. Next to nothing going on in top. Killing off the attempted install or guest start up seems to put xend in a bad state (xm list says "Error: Device 51712 not connected"), and attempting to restart xend (or the entire system) hangs it up completely.
Jarod, have you tried blktap with the agriffis4 kernel mentioned on ipf-virtualization? It works well for me. I think your experience in comment 16 probably relates to missing some fixes later in the patchset, though I'm not sure which ones.
Heh, looks like I really ought to see about getting added to the ipf-virtualization mailing list. In the mean time, Prarit has hooked me up, and I'm grabbing agriffis4 bits right now, will let you know how it goes...
In poking at your srpm and mine, the only difference is you've got two additional patches, kernel-2.6.18-1.2747-ia64-linux-kuwa.patch and kernel-2.6.18-1.2747-ia64-xen-kuwa.patch. Will get to testing after lunch...
Unfortunately, the kuwa patches don't make a difference in the behavior on this box. Tried both my own build and all your builds, same results, system hangs just like in comment #16. The system I'm working on is an HP zx2000. I'll tinker with some other ia64 hardware here to see what happens there...
Okay, so the zx2000 gets completely hosed up, while on another ia64 box, a guest install fails with a kernel panic of the guest, but dom0 keeps chugging along.
Comment on attachment 141558 [details] blktap/ia64 patches ported to rhel5 Obsoleted by patch 142795.
Comment on attachment 141558 [details] blktap/ia64 patches ported to rhel5 Obsoleted by patch in attachment 142795 [details].
The patch in attachment 142795 [details], applied atop kernel 2.6.18-1.2789.el5 performs marginally better than the prior patch. A guest trying to use blktap still fails to start up, encountering a kernel panic, but at least its no longer causing the zx2000 to get completely fubar'd. Console output from failed guest boot using blktap (there's a lengthy hang after "Loading xenblk.ko module"): Red Hat nash version 5.1.19.1 starting Mounting proc filesystem Mounting sysfs filesystem Creating /dev Creating initial device nodes Setting up hotplug. Creating block device nodes. Loading uhci-hcd.ko module USB Universal Host Controller Interface driver v3.0 Loading ohci-hcd.ko module Loading ehci-hcd.ko module Loading jbd.ko module Loading ext3.ko module Loading xenblk.ko module XENBUS: Timeout connecting to device: device/vbd/51712 (state 3) Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init!
Urk. Ignore the prior comment for a sec... Just realized that while I did apply the newer blktap patch, the config file got reset and I forgot to set CONFIG_XEN_BLKDEV_TAP=m, so rebuilding and retesting...
change QA contact
This report targets FC6, which is now end-of-life. Please re-test against Fedora 7 or later, and if the issue persists, open a new bug. Thanks