Bug 208895 - blktap does not build on ia64
Summary: blktap does not build on ia64
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-xen   
(Show other bugs)
Version: rawhide
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Aron Griffis
QA Contact: Virtualization Bugs
Depends On:
Blocks: 209321 212315
TreeView+ depends on / blocked
Reported: 2006-10-02 15:22 UTC by Stephen Tweedie
Modified: 2009-12-14 20:37 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-26 23:29:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
blktap compile fix for ia64 (2.05 KB, patch)
2006-10-02 15:29 UTC, Chris Wright
no flags Details | Diff
blktap/ia64 patches ported to rhel5 (14.13 KB, patch)
2006-11-18 17:58 UTC, Aron Griffis
no flags Details | Diff

Description Stephen Tweedie 2006-10-02 15:22:49 UTC
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

Version-Release number of selected component (if applicable):

blktap has been disabled on ia64 for now:
$ grep TAP configs/*xen*
configs/config-xen-ia64:# CONFIG_XEN_BLKDEV_TAP is not set

Comment 1 Chris Wright 2006-10-02 15:29:51 UTC
Created attachment 137553 [details]
blktap compile fix for ia64

Comment 2 Chris Wright 2006-10-02 15:36:16 UTC
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.

Comment 3 Stephen Tweedie 2006-10-02 16:15:45 UTC
Yes; the backend allocating issue is already being tracked as bug 202971.

Comment 4 Chris Wright 2006-10-02 16:20:54 UTC
OK, in that case we could apply the blktap fix to get things working to a point
that they can be debugged.

Comment 5 Prarit Bhargava 2006-10-04 16:00:00 UTC
Assigning to agriffis.

Comment 6 Atsushi SAKAI 2006-10-16 11:15:28 UTC
GNTMAP_application_map does not support Xen/IA64.
the blktap uses this function, so it does not run.
even if it fixes compilation.

Comment 7 You, Yongkang 2006-10-17 02:10:31 UTC
This bug is still in kernel-xen-2.6.18-1.2784.fc6

Comment 8 Don Zickus 2006-10-17 02:34:17 UTC
in kernel-2.6.18-1.2728.el5

Comment 9 Stephen Tweedie 2006-10-17 08:41:26 UTC
Reopening, because the el5 kernel is not a fix for a devel bug!

Comment 10 Aron Griffis 2006-10-25 18:22:35 UTC
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

Hopefully this will be fixed upstream in time for RHEL5 release.  Unfortunately
it didn't make FC6

Comment 11 Aron Griffis 2006-11-08 20:22:56 UTC
Isaku Yamahata (Fujitsu) finished this work.  It is now in xen-unstable:


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.

Comment 12 Aron Griffis 2006-11-18 17:58:37 UTC
Created attachment 141558 [details]
blktap/ia64 patches ported to rhel5

Comment 13 Aron Griffis 2006-11-18 19:36:06 UTC
Note that the blktap patches also require this change in


Comment 14 Aron Griffis 2006-11-18 20:57:34 UTC
Note that attachment 141558 [details] should obsolete attachment 137553 [details] but I didn't have
permissions to do that.

Comment 15 Jarod Wilson 2006-11-27 22:24:33 UTC
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...

Comment 16 Jarod Wilson 2006-11-28 17:05:15 UTC
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.
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>

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.

Comment 17 Aron Griffis 2006-11-30 13:54:20 UTC
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.

Comment 18 Jarod Wilson 2006-11-30 16:02:22 UTC
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...

Comment 19 Jarod Wilson 2006-11-30 17:01:54 UTC
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...

Comment 20 Jarod Wilson 2006-11-30 20:45:48 UTC
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...

Comment 21 Jarod Wilson 2006-11-30 23:22:38 UTC
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 22 Jarod Wilson 2006-12-05 02:04:46 UTC
Comment on attachment 141558 [details]
blktap/ia64 patches ported to rhel5

Obsoleted by patch 142795.

Comment 23 Jarod Wilson 2006-12-05 02:05:26 UTC
Comment on attachment 141558 [details]
blktap/ia64 patches ported to rhel5

Obsoleted by patch in attachment 142795 [details].

Comment 24 Jarod Wilson 2006-12-05 16:51:41 UTC
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 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!

Comment 25 Jarod Wilson 2006-12-05 17:00:45 UTC
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...

Comment 26 Red Hat Bugzilla 2007-07-25 01:33:55 UTC
change QA contact

Comment 27 Chris Lalancette 2008-02-26 23:29:31 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.