[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-4.1-testing test] 14689: regressions - FAIL
>>> On 14.12.12 at 12:45, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote: > flight 14689 xen-4.1-testing real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/14689/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-qemut-rhel6hvm-amd 11 leak-check/check fail REGR. vs. > 14679 > test-amd64-amd64-xl 18 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-qemuu-rhel6hvm-intel 11 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-rhel6hvm-intel 11 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-xl-multivcpu 18 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-xl 18 leak-check/check fail REGR. vs. > 14679 > test-i386-i386-xl 18 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-xl-credit2 18 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-qemuu-rhel6hvm-amd 11 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-rhel6hvm-amd 11 leak-check/check fail REGR. vs. > 14679 > test-amd64-i386-qemut-rhel6hvm-intel 11 leak-check/check fail REGR. vs. > 14679 So this is what really should not have happened past the intended-to-be-final RC. > ------------------------------------------------------------ > changeset: 23428:93e17b0cd035 > tag: tip > user: Greg Wettstein <greg@xxxxxxxxxxxx> > date: Thu Dec 13 14:35:58 2012 +0000 > > libxl: avoid blktap2 deadlock on cleanup > > Establishes correct cleanup behavior for blktap devices. This patch > implements the release of the backend device before calling for > the destruction of the userspace component of the blktap device. > > Without this patch the kernel xen-blkback driver deadlocks with > the blktap2 user control plane until the IPC channel is terminated by > the > timeout on the select() call. This results in a noticeable delay > in the termination of the guest and causes the blktap minor > number which had been allocated to be orphaned. > > Signed-off-by: Greg Wettstein <greg@xxxxxxxxxxxx> > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> > Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> How important is this change really to the 4.1 tree? I'd obviously favor outright reverting it at this point (my understanding being that the removal of the call to xs_rm() from libxl__device_destroy() affected more than just tapdisk backends, which I guess was assumed to be the case because of its neighboring with the call to libxl__device_destroy_tapdisk()). Would that get the tree into worse state that 4.1.3 was in? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |