Red Hat Bugzilla – Bug 216293
blktap does not build on ia64
Last modified: 2013-07-03 09:26:55 EDT
+++ This bug was initially created as a clone of Bug #208895 +++
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
-- Additional comment from firstname.lastname@example.org on 2006-10-02 11:29 EST --
Created an attachment (id=137553)
blktap compile fix for ia64
-- Additional comment from email@example.com on 2006-10-02 11:36 EST --
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.
-- Additional comment from firstname.lastname@example.org on 2006-10-02 12:15 EST --
Yes; the backend allocating issue is already being tracked as bug 202971.
-- Additional comment from email@example.com on 2006-10-02 12:20 EST --
OK, in that case we could apply the blktap fix to get things working to a point
that they can be debugged.
-- Additional comment from firstname.lastname@example.org on 2006-10-04 12:00 EST --
Assigning to agriffis.
-- Additional comment from email@example.com on 2006-10-16 07:15 EST --
GNTMAP_application_map does not support Xen/IA64.
the blktap uses this function, so it does not run.
even if it fixes compilation.
-- Additional comment from firstname.lastname@example.org on 2006-10-16 22:10 EST --
This bug is still in kernel-xen-2.6.18-1.2784.fc6
-- Additional comment from email@example.com on 2006-10-16 22:34 EST --
-- Additional comment from firstname.lastname@example.org on 2006-10-17 04:41 EST --
Reopening, because the el5 kernel is not a fix for a devel bug!
-- Additional comment from email@example.com on 2006-10-25 14:22 EST --
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
-- Additional comment from firstname.lastname@example.org on 2006-11-08 15:22 EST --
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.
-- Additional comment from email@example.com on 2006-11-18 12:58 EST --
Created an attachment (id=141558)
blktap/ia64 patches ported to rhel5
-- Additional comment from firstname.lastname@example.org on 2006-11-18 14:36 EST --
Note that the blktap patches also require this change in
-# CONFIG_XEN_BLKDEV_TAP is not set
*** Bug 212315 has been marked as a duplicate of this bug. ***
Note that attachment 141558 [details] should obsolete attachment 137553 [details] but I didn't have
permissions to do that.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
Per discussion with Prarit and Aron,
> Bug 212315/216293: blktap does not build on ia64
> This is completely fixed upstream and is important for the tech
> preview. I just need to post the patches ported to RHEL5. I will do
> that ASAP.
Should be an RC blocker.
Aron please ACK for devel; QE please ACK/NAK as appropriate.
Note that the patch in comment #2 is more complicated that others in this group.
Affects drivers/xen/blktap/blktapmain.c and drivers/xen/blktap/xenbus.c.
I put this on rhkernel-list today so we should get some comments back about the
common code mods.
Created attachment 142795 [details]
Updated blktap patch, as posted for internal review
This patch obsoletes attachment 141558 [details].
If blktap is building/working on IA64, this should be closed.
Well... First ia64 xen kernels have to actually be able to *boot*... :)
(bug 241674 and bug 243312)
...still not building. With the config option flipped back on in the latest
drivers/xen/blktap/blktapmain.c: In function 'fast_flush_area':
drivers/xen/blktap/blktapmain.c:859: error: implicit declaration of function
make: *** [drivers/xen/blktap/blktapmain.o] Error 1
make: *** [drivers/xen/blktap] Error 2
make: *** [drivers/xen] Error 2
make: *** [drivers] Error 2
I've got the blktap module compiling now, but not behaving entirely. Though it
could be something else actually causing my problems, so stay tuned. More info
to come later tonight. Current patch was posted to rhkernel-list earlier
tonight, and there's a slightly different version that made its way into the
upstream xen-unstable hg tree:
Created attachment 157513 [details]
Further updated patch, actually builds *and* works! (at least mostly)
This is the version of the patch with which I'm actually able to use blktap to
access a disk image, install a guest with, etc. Only issue at the moment, so
far as I can tell, is top reporting some insane memory usage from tapdisk. Its
reporting figures several orders of magnitude greater than the amount of memory
in the system (its claiming to use 2000% of memory), but swap isn't being
abnormally used, no oom-kills, etc., so it may just be an accounting error of
some sort, since I can't see any other ill effects.
Guest install finished just fine, no more tapdisk process reporting gross memory usage once its shut
down. More testing in the morning.
Patch submitted for internal review.
Updated patch including a one-line-of-code addition from fujitsu to eliminate
the tapdisk memory issue posted for review.
We still have one remaining problem with some dom0 console spew on domU bootup
blk_tap: BLKTAP: READ request sector[8192002,16000], Total 
blk_tap: BLKTAP: Sector request greaterthan size
This happens on bootup within the initrd. After some initrd hacking
(basically, adding a bunch of sleep calls between steps), I've
determined that there are two distinct bursts of spew, one that
coincides with "Creating root device." (aka mkrootdev -t ext3 ...) and
one with "Mounting root filesystem." (aka mount /sysroot). Doesn't
matter if root is on lvm or a plain partition, happens the same way on a
guest with no lvm whatsoever and a guest w/lvm. Haven't yet been able to
trigger this spew doing heavy I/O within the guest either, thus far it
has only been triggered in the initrd.
From Jun 28 RHEL 5 meeting:
STATUS: More progress. Are booting and testing. Fujitsu doesn't
Update: in POST as of Jun 21 PM.
STATUS: Fujitsu just gave another patch Jun 27.
DECISION: Add to potential Beta respin of kernel.
Copied dzickus on bugzilla.
You can download this test kernel from http://people.redhat.com/dzickus/el5
Per comment #24, looks like Fujitsu provided the patch.
Assume they will test this fix.
Confirmed that blktap is building on ia64 as of the -43 kernel
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.