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