On Thu, 2010-07-01 at 08:55 -0400, tsk wrote:
> Hi, will the patches be added to Xen-4.1？
About to prepare the next bunch of patches for xen.git.
Jeremy, is it okay to pull some of the changes made for 2.6.3x into the
xen/dom0/backend/blktap2 topic branch before moving on?
I'm mainly talking about this one:
>From ab77527f9a63a5c657c6d6a50e70a66adceaa3a0 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
Date: Thu, 18 Feb 2010 17:22:09 -0800
Subject: [PATCH] xen/blktap2: make compile
and a couple related deltas which came later.
Except moving forward to newer blk queue interfaces, they don't make
much of a functional difference.
Would simplify merging quite a bit.
Daniel
>
> 2010/6/28 Daniel Stodden <daniel.stodden@xxxxxxxxxx>
> On Mon, 2010-06-28 at 00:58 -0400, tsk wrote:
> > It is found that some assertion was in the tapdisk2 source,
> if anyone
> > failed, the tapdisk2 process will exit,
> > They are very dangerous...
> > How can the kernel handle this if the tapdisk2 process exit?
>
>
> There would be multiple ways.
>
> One is to recover in-flight I/O and wait for a new tapdisk to
> start,
> then reissue. There's not a real usecase for this, but think
> watchdog.
> Maybe someday.
>
> The present strategy is to:
> - Fail pending I/O.
> - Restart the disk I/O queue, thereby flushing everything
> submitted
> to the block device with EIO as well.
> - Release the block device after the last opener finally gave
> up.
>
> Works well. At least from a dom0 perspective ;)
>
> Daniel
>
>
> >
> >
> > 2010/6/28 Daniel Stodden <daniel.stodden@xxxxxxxxxx>
> > On Mon, 2010-06-28 at 00:41 -0400, tsk wrote:
> > > Hi folks,
> > >
> > >
> > > Yestoday, I run a testcase, 6 VMs restart every 10
> minitues
> > from 11:00
> > > am to 16:30 pm until Dom0 crashed.
> > >
> > > Assertion 'list_empty(&vreq->next)' failed will
> lead to
> > tapdisk2
> > > process segfault, then Dom0 crashed!
> > >
> > >
> > > Jun 27 16:31:05 r02k05014 kernel: device tap775.0
> entered
> > promiscuous
> > > mode
> > > Jun 27 16:31:05 r02k05014 kernel: eth0: port
> 13(tap775.0)
> > entering
> > > forwarding state
> > > Jun 27 16:31:15 r02k05014 tapdisk2[4341]:
> Assertion
> > > 'list_empty(&vreq->next)' failed, line 1822, file
> > tapdisk-vbd.c
> > > Jun 27 16:31:15 r02k05014 kernel: tapdisk2[4341]:
> segfault
> > at 0 ip
> > > 000000000040a24f sp 00007fff0d8acb70 error 6 in
> > tapdisk2[400000+39000]
> > > Jun 28 18:58:09 r02k05014 syslogd 1.4.1: restart.
> > >
> > >
> > > Any one who can give me some tips?
> >
> >
> > Semi-yes. Not entirely sure about the list_empty
> userland
> > crasher, but
> > the kernel stuff was upstreamed with some minor
> exposed while
> > unmapping
> > pending I/O.
> >
> > Which I didn't care yet to send patches for...
> >
> > ... Soon, real soon now...
> >
> > Daniel
> >
> >
> >
> >
> >
> >
>
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home