Xen devel - May 2007 - blktap failure after 14895:800aa9f5cec9 (moves /dev/xen/... to /var/run/tap/...)

I don''t know why I''m the only one to see this, but blktap
hasn''t been
working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
/dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.

Reverting the change to blktaplib.h gives me blktap devices
again. Reads and writes don''t seem to make any progress. I''ll
keep
investigating, but any clues would be welcome.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/5/07 03:48, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
> I don''t know why I''m the only one to see this, but blktap
hasn''t been
> working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
> fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
> /dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
> tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.
> 
> Reverting the change to blktaplib.h gives me blktap devices
> again. Reads and writes don''t seem to make any progress.
I''ll keep
> investigating, but any clues would be welcome.
More likely it''s simply because /var/run/tap/ doesn''t exist?

Either some startup script needs to ''mkdir -p'', or blktapctrl
needs to make
the directory on demand.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wednesday, 02 May 2007 at 13:51, Keir Fraser wrote:
> On 2/5/07 03:48, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
> 
> > I don''t know why I''m the only one to see this, but
blktap hasn''t been
> > working for me since 14895:800aa9f5cec9. Opening /var/run/tap/blktap0
> > fails. I think this is because the kernel defines BLKTAP_DEV_DIR as
> > /dev/xen in drivers/xen/blktap/blktap.c, but in that changeset the
> > tools define it as /var/run/tap in tools/blktap/lib/blktaplib.h.
> > 
> > Reverting the change to blktaplib.h gives me blktap devices
> > again. Reads and writes don''t seem to make any progress.
I''ll keep
> > investigating, but any clues would be welcome.
> 
> More likely it''s simply because /var/run/tap/ doesn''t
exist?
> 
> Either some startup script needs to ''mkdir -p'', or
blktapctrl needs to make
> the directory on demand.
the blktap tools do create that directory on demand, and in fact
/var/run/tap/blktap0 is properly created. What fails is the
''open'',
somewhere in the kernel I believe. Maybe this only affects
block-attaching a device in domain 0?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2/5/07 16:11, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
>> More likely it''s simply because /var/run/tap/ doesn''t
exist?
>> 
>> Either some startup script needs to ''mkdir -p'', or
blktapctrl needs to make
>> the directory on demand.
> 
> the blktap tools do create that directory on demand, and in fact
> /var/run/tap/blktap0 is properly created. What fails is the
''open'',
> somewhere in the kernel I believe. Maybe this only affects
> block-attaching a device in domain 0?
The open() that''s part of mkfifo()? Those FIFO files have nothing to do
with
the blktap kernel module, I believe, in which case this can''t have
anything
to do with a mismatch of something between blktap user and blktap kernel.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wednesday, 02 May 2007 at 16:19, Keir Fraser wrote:
> 
> 
> 
> On 2/5/07 16:11, "Brendan Cully" <brendan@cs.ubc.ca> wrote:
> 
> >> More likely it''s simply because /var/run/tap/
doesn''t exist?
> >> 
> >> Either some startup script needs to ''mkdir -p'',
or blktapctrl needs to make
> >> the directory on demand.
> > 
> > the blktap tools do create that directory on demand, and in fact
> > /var/run/tap/blktap0 is properly created. What fails is the
''open'',
> > somewhere in the kernel I believe. Maybe this only affects
> > block-attaching a device in domain 0?
> 
> The open() that''s part of mkfifo()? Those FIFO files have nothing
to do with
> the blktap kernel module, I believe, in which case this can''t have
anything
> to do with a mismatch of something between blktap user and blktap kernel.
The open of blktap0 (the character device).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

The attached patch fixes the problem for me (well, my qcow tapdisk is
still hanging, but that''s a separate issue).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel