Hello, I''m using both xen 4.0.1-rc5 and the latest pv_ops dom0 kernel (branch xen/stable-2.6.32.x), but I''m having some problems with tapdisk2... Basically, if I create a tap device (tapdisk2 -n aio:/var/lib/libvirt/images/srv-001-ub1004.img), when I try to terminate it by issuing "echo 1 > /sys/class/blktap2/blktap0/remove", the last command hangs and tapdisk2 hangs using 100% cpu. This happens both on manual device destruction and on virtual machine shutdown. I don''t know exactly what triggered this behaviour, but I suspect kernel changes. Can anyone confirm this behaviour? Thanks, Luís _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello again, I''ve tried updating the kernel as blktap has had some work on it, but the problem remains. The up to date xen/stable-2.6.32.x still behaves as described bellow. Also, I''ve tested this procedure against kernel 2.6.34.1 with Suse backported patches and the problem doesn''t exist. I haven''t still tried updating xen to 4.0.1-rc6, but from the changelog I don''t see anything that could change this behaviour... Is anyone with an up to date xen/stable-2.6.32.x kernel seeing this problem or is it just I? Thanks, Luís On Wed, 2010-08-04 at 15:04 +0100, Luís Silva wrote:> Hello, > > I''m using both xen 4.0.1-rc5 and the latest pv_ops dom0 kernel (branch > xen/stable-2.6.32.x), but I''m having some problems with tapdisk2... > > Basically, if I create a tap device (tapdisk2 -n > aio:/var/lib/libvirt/images/srv-001-ub1004.img), when I try to > terminate it by issuing "echo 1 > /sys/class/blktap2/blktap0/remove", > the last command hangs and tapdisk2 hangs using 100% cpu. > > This happens both on manual device destruction and on virtual machine > shutdown. I don''t know exactly what triggered this behaviour, but I > suspect kernel changes. > > Can anyone confirm this behaviour? > > Thanks, > Luís > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Aug 15, 2010 at 05:14:01PM +0100, Luís Silva wrote:> Hello again, > > I''ve tried updating the kernel as blktap has had some work on it, but the > problem remains. The up to date xen/stable-2.6.32.x still behaves as > described bellow. Also, I''ve tested this procedure against kernel 2.6.34.1 > with Suse backported patches and the problem doesn''t exist. I haven''t > still tried updating xen to 4.0.1-rc6, but from the changelog I don''t see > anything that could change this behaviour... > > Is anyone with an up to date xen/stable-2.6.32.x kernel seeing this > problem or is it just I? >What''s the previous xen/stable-2.6.32.x version that works for you? -- Pasi> Thanks, > Luís > > On Wed, 2010-08-04 at 15:04 +0100, Luís Silva wrote: > > Hello, > > I''m using both xen 4.0.1-rc5 and the latest pv_ops dom0 kernel (branch > xen/stable-2.6.32.x), but I''m having some problems with tapdisk2... > > Basically, if I create a tap device (tapdisk2 -n > aio:/var/lib/libvirt/images/srv-001-ub1004.img), when I try to terminate > it by issuing "echo 1 > /sys/class/blktap2/blktap0/remove", the last > command hangs and tapdisk2 hangs using 100% cpu. > > This happens both on manual device destruction and on virtual machine > shutdown. I don''t know exactly what triggered this behaviour, but I > suspect kernel changes. > > Can anyone confirm this behaviour? > > Thanks, > Luís > > _______________________________________________ > Xen-devel mailing list > [1]Xen-devel@lists.xensource.com > [2]http://lists.xensource.com/xen-devel > > References > > Visible links > 1. mailto:Xen-devel@lists.xensource.com > 2. http://lists.xensource.com/xen-devel> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2010-08-04 at 10:04 -0400, Luís Silva wrote:> Hello, > > I''m using both xen 4.0.1-rc5 and the latest pv_ops dom0 kernel (branch > xen/stable-2.6.32.x), but I''m having some problems with tapdisk2... > > Basically, if I create a tap device (tapdisk2 -n > aio:/var/lib/libvirt/images/srv-001-ub1004.img), when I try to > terminate it by issuing "echo 1 > /sys/class/blktap2/blktap0/remove", > the last command hangs and tapdisk2 hangs using 100% cpu. > > This happens both on manual device destruction and on virtual machine > shutdown. I don''t know exactly what triggered this behaviour, but I > suspect kernel changes. > > Can anyone confirm this behaviour?Yes, with a broken userland. I thought Ian''s dot-private patches to ring.h made it into testing? changeset: 21707:feee0abed6aa user: Keir Fraser <keir.fraser@citrix.com> date: Fri Jul 02 18:58:02 2010 +0100 summary: blktap2: make protocol specific usage of shared sring explicit The problem is that the kernel has those changes. What''s going to happen is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 as intended, it will fail to find/clear the ring message, while the kernel will keep it spinning through select(), and that''s what you''re seeing. Keir, okay to just pull that stuff? Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> wrote:> The problem is that the kernel has those changes. What''s going to happen > is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 > as intended, it will fail to find/clear the ring message, while the > kernel will keep it spinning through select(), and that''s what you''re > seeing. > > Keir, okay to just pull that stuff?What stuff to where? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote:> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > > > The problem is that the kernel has those changes. What''s going to happen > > is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 > > as intended, it will fail to find/clear the ring message, while the > > kernel will keep it spinning through select(), and that''s what you''re > > seeing. > > > > Keir, okay to just pull that stuff? > > What stuff to where?changeset: 21707:feee0abed6aa user: Keir Fraser <keir.fraser@citrix.com> date: Fri Jul 02 18:58:02 2010 +0100 summary: blktap2: make protocol specific usage of shared sring explicit Into 4.0.1. The offsets were broken by changeset: 20267:e9366bed077e user: Keir Fraser <keir.fraser@citrix.com> date: Thu Oct 01 12:27:01 2009 +0100 summary: VNIF: Using smart polling instead of event notification. Not so good? Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15/08/2010 21:36, "Daniel Stodden" <daniel.stodden@citrix.com> wrote:> On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote: >> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: >> >>> The problem is that the kernel has those changes. What''s going to happen >>> is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 >>> as intended, it will fail to find/clear the ring message, while the >>> kernel will keep it spinning through select(), and that''s what you''re >>> seeing. >>> >>> Keir, okay to just pull that stuff? >> >> What stuff to where? > > changeset: 21707:feee0abed6aa > user: Keir Fraser <keir.fraser@citrix.com> > date: Fri Jul 02 18:58:02 2010 +0100 > summary: blktap2: make protocol specific usage of shared sring > explicit > > Into 4.0.1.Okay, done. K.> The offsets were broken by > > changeset: 20267:e9366bed077e > user: Keir Fraser <keir.fraser@citrix.com> > date: Thu Oct 01 12:27:01 2009 +0100 > summary: VNIF: Using smart polling instead of event notification. > > Not so good?> Daniel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 2010-08-15 at 16:48 -0400, Keir Fraser wrote:> On 15/08/2010 21:36, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > > > On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote: > >> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > >> > >>> The problem is that the kernel has those changes. What''s going to happen > >>> is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 > >>> as intended, it will fail to find/clear the ring message, while the > >>> kernel will keep it spinning through select(), and that''s what you''re > >>> seeing. > >>> > >>> Keir, okay to just pull that stuff? > >> > >> What stuff to where? > > > > changeset: 21707:feee0abed6aa > > user: Keir Fraser <keir.fraser@citrix.com> > > date: Fri Jul 02 18:58:02 2010 +0100 > > summary: blktap2: make protocol specific usage of shared sring > > explicit > > > > Into 4.0.1. > > Okay, done.Thanks! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sunday 15 August 2010 23:54:43 Daniel Stodden wrote:> On Sun, 2010-08-15 at 16:48 -0400, Keir Fraser wrote: > > On 15/08/2010 21:36, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > > > On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote: > > >> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com>wrote:> > >>> The problem is that the kernel has those changes. What''s going to > > >>> happen is that if tapdisk2 anticipates the ring ''message'' at offset > > >>> 17, not 16 as intended, it will fail to find/clear the ring message, > > >>> while the kernel will keep it spinning through select(), and that''s > > >>> what you''re seeing. > > >>> > > >>> Keir, okay to just pull that stuff? > > >> > > >> What stuff to where? > > > > > > changeset: 21707:feee0abed6aa > > > user: Keir Fraser <keir.fraser@citrix.com> > > > date: Fri Jul 02 18:58:02 2010 +0100 > > > summary: blktap2: make protocol specific usage of shared sring > > > explicit > > > > > > Into 4.0.1. > > > > Okay, done. > > Thanks!Where can I find this change? I am using xen-4.0-testing.hg but the last chnage is a few days old? Thanks, -- Michael Brade; KDE Developer |-mail: echo brade !#|tr -d "c oh"|s\e\d ''s/e/\@/2;s/$/.org/;s/bra/k/2'' °--web: http://www.behindkde.org/people/michaelb/ KDE 4: Beyond Your Expectations _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Aug 16, 2010 at 12:07:35AM +0200, Michael Brade wrote:> On Sunday 15 August 2010 23:54:43 Daniel Stodden wrote: > > On Sun, 2010-08-15 at 16:48 -0400, Keir Fraser wrote: > > > On 15/08/2010 21:36, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > > > > On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote: > > > >> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> > wrote: > > > >>> The problem is that the kernel has those changes. What''s going to > > > >>> happen is that if tapdisk2 anticipates the ring ''message'' at offset > > > >>> 17, not 16 as intended, it will fail to find/clear the ring message, > > > >>> while the kernel will keep it spinning through select(), and that''s > > > >>> what you''re seeing. > > > >>> > > > >>> Keir, okay to just pull that stuff? > > > >> > > > >> What stuff to where? > > > > > > > > changeset: 21707:feee0abed6aa > > > > user: Keir Fraser <keir.fraser@citrix.com> > > > > date: Fri Jul 02 18:58:02 2010 +0100 > > > > summary: blktap2: make protocol specific usage of shared sring > > > > explicit > > > > > > > > Into 4.0.1. > > > > > > Okay, done. > > > > Thanks! > > Where can I find this change? I am using xen-4.0-testing.hg but the last chnage > is a few days old? >It''s in: http://xenbits.xen.org/staging/xen-4.0-testing.hg -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Aug 15, 2010 at 09:48:45PM +0100, Keir Fraser wrote:> On 15/08/2010 21:36, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > > > On Sun, 2010-08-15 at 16:28 -0400, Keir Fraser wrote: > >> On 15/08/2010 20:35, "Daniel Stodden" <daniel.stodden@citrix.com> wrote: > >> > >>> The problem is that the kernel has those changes. What''s going to happen > >>> is that if tapdisk2 anticipates the ring ''message'' at offset 17, not 16 > >>> as intended, it will fail to find/clear the ring message, while the > >>> kernel will keep it spinning through select(), and that''s what you''re > >>> seeing. > >>> > >>> Keir, okay to just pull that stuff? > >> > >> What stuff to where? > > > > changeset: 21707:feee0abed6aa > > user: Keir Fraser <keir.fraser@citrix.com> > > date: Fri Jul 02 18:58:02 2010 +0100 > > summary: blktap2: make protocol specific usage of shared sring > > explicit > > > > Into 4.0.1. > > Okay, done. >Btw will there be -rc7 now with these changes? -- Pasi> K. > > > The offsets were broken by > > > > changeset: 20267:e9366bed077e > > user: Keir Fraser <keir.fraser@citrix.com> > > date: Thu Oct 01 12:27:01 2009 +0100 > > summary: VNIF: Using smart polling instead of event notification. > > > > Not so good? > > > Daniel > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/08/2010 08:02, "Pasi Kärkkäinen" <pasik@iki.fi> wrote:>>> changeset: 21707:feee0abed6aa >>> user: Keir Fraser <keir.fraser@citrix.com> >>> date: Fri Jul 02 18:58:02 2010 +0100 >>> summary: blktap2: make protocol specific usage of shared sring >>> explicit >>> >>> Into 4.0.1. >> >> Okay, done. > > Btw will there be -rc7 now with these changes?I''m not planning on doing an RC7. The two patches applied since RC6 are very limited and obvious in their scope and impact. AFAIAC we are still on for release at the end of the week. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Monday 16 August 2010 08:56:16 Pasi Kärkkäinen wrote:> On Mon, Aug 16, 2010 at 12:07:35AM +0200, Michael Brade wrote: > > Where can I find this change? I am using xen-4.0-testing.hg but the last > > chnage is a few days old? > > It''s in: > http://xenbits.xen.org/staging/xen-4.0-testing.hgGreat, thanks! So whats the difference between http://xenbits.xensource.com/xen-4.0-testing.hg http://xenbits.xen.org/staging/xen-4.0-testing.hg Is the former meant to be used at all? Thanks, -- Michael Brade; KDE Developer |-mail: echo brade !#|tr -d "c oh"|s\e\d ''s/e/\@/2;s/$/.org/;s/bra/k/2'' °--web: http://www.behindkde.org/people/michaelb/ KDE 4: Beyond Your Expectations _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 18/08/2010 18:17, "Michael Brade" <brade@kde.org> wrote:> Great, thanks! So whats the difference between > > http://xenbits.xensource.com/xen-4.0-testing.hg > http://xenbits.xen.org/staging/xen-4.0-testing.hg > > Is the former meant to be used at all?Staging gets pushed there when it passes some automated tests. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser writes ("Re: [Xen-devel] Tapdisk2
problem"):> On 18/08/2010 18:17, "Michael Brade" <brade@kde.org> wrote:
> > Great, thanks! So whats the difference between
> >
> > http://xenbits.xensource.com/xen-4.0-testing.hg
> > http://xenbits.xen.org/staging/xen-4.0-testing.hg
> >
> > Is the former meant to be used at all?
>
> Staging gets pushed there when it passes some automated tests.
Unfortunately those tests have been failing recently which is why the
main 4.0-testing tree is out of date. We''re working on finding and
fixing the problem, before releasing 4.0.1 !
(Also there is no meaningful difference in the domain name:
xenbits.xen.org is the new name for xenbits.xensource.com.)
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel