Re: [Xen-devel] [xen-unstable test] 106812: regressions - FAIL

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Wed, Mar 22, 2017 at 03:32:34AM -0600, Jan Beulich wrote:
> >>> On 22.03.17 at 06:50, <osstest-admin@xxxxxxxxxxxxxx> wrote:
> > flight 106812 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/106812/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qcow2    10 guest-start              fail REGR. vs. 
> > 106802
> >  test-amd64-amd64-xl-pvh-amd 19 guest-start/debian.repeat fail REGR. vs. 
> > 106802
> 
> I'm not sure whether these are the reason for the test failure (it
> seems likely though, as the earlier 14 instances didn't show these),
> but
> 
> Mar 21 21:45:33.777625 [  694.126505] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.729658 [  694.126535] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.737587 [  694.126545] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.745591 [  694.126553] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.745629 [  694.126562] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.753605 [  694.126570] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.761604 [  694.126579] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.769595 [  694.126587] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.777590 [  694.126596] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.785587 [  694.126604] xen-blkback: trying to add a gref 
> that's already in the tree
> Mar 21 21:45:34.785624 [  694.126643] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.793588 [  694.126707] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.801583 [  694.126755] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.809590 [  694.126803] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.809626 [  694.126850] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.817647 [  694.126898] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.825706 [  694.126945] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.825751 [  694.126991] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.833803 [  694.127038] xen-blkback: requesting a grant already 
> in use
> Mar 21 21:45:34.841761 [  694.127085] xen-blkback: requesting a grant already 
> in use
> 
> clearly look like something went wrong here.

Hm, yes, it's hard to tell what went wrong, but I assume the same grant was
used more than once inside the same request, and across multiple requests
concurrently. Sadly there's not much information on the guest itself:

[    2.454624] traps: systemd[1] general protection ip:7f63eb50f3fc 
sp:7ffd1a1109d0 error:0 in systemd[7f63eb4b0000+122000]
[    2.455230] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0000000b
[    2.455230] 
[    2.455257] CPU: 0 PID: 1 Comm: systemd Not tainted 3.14.79+ #1
[    2.455269]  0000000000000000 ffff88001e84dca0 ffffffff817a2404 
ffffffff819aafd0
[    2.455289]  ffff88001e84dd30 ffff88001e84dd20 ffffffff817a0dd5 
ffff880000000010
[    2.455309]  ffff88001e84dd30 ffff88001e84dcc8 0000000000000004 
000000000000000b
[    2.455328] Call Trace:
[    2.455345]  [<ffffffff817a2404>] dump_stack+0x7c/0x98
[    2.455359]  [<ffffffff817a0dd5>] panic+0xcd/0x1e3
[    2.455374]  [<ffffffff810b0dd6>] do_exit+0xae6/0xaf0
[    2.455387]  [<ffffffff810b1e0e>] do_group_exit+0x3e/0xc0
[    2.455401]  [<ffffffff810c24a5>] get_signal_to_deliver+0x275/0x940
[    2.455416]  [<ffffffff81064653>] do_signal+0x43/0x790
[    2.455430]  [<ffffffff810c03de>] ? __send_signal+0x13e/0x440
[    2.455447]  [<ffffffff810c0719>] ? send_signal+0x39/0x80
[    2.455460]  [<ffffffff817ab6d9>] ? _raw_spin_unlock_irqrestore+0x29/0x90
[    2.455475]  [<ffffffff810c111c>] ? force_sig_info+0xcc/0xe0
[    2.455490]  [<ffffffff81064e05>] do_notify_resume+0x65/0x80
[    2.455504]  [<ffffffff817abd22>] retint_signal+0x48/0x86

Maybe the grant list went corrupt inside of the guest?

Note that although the test says "pvh" this is now booting as a PV guest,
because the pvh=1 option is not implemented. There's a fsck going on before
this happens, but again I'm not sure if that's triggered because Linux detects
a non-clean fs or if it's just part of the boot.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel