[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-4.5-testing test] 59792: regressions - FAIL

flight 59792 xen-4.5-testing real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-boot                 fail REGR. vs. 59527
 test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail REGR. 
vs. 59527

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59527
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail blocked in 
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop             fail like 59508
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop              fail like 59527
 test-armhf-armhf-xl-rtds     11 guest-start                  fail   like 59527

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start                  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start                  fail  never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check        fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check        fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop             fail never pass
 test-armhf-armhf-xl          12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  666b80f239c566283cb1b3435180d99a329d0156
baseline version:
 xen                  36a7c54a698db7d087873b312087cfa64de33175

Last test of basis    59527  2015-07-14 01:40:53 Z    7 days
Testing same since    59792  2015-07-21 09:35:47 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Liang Li <liang.z.li@xxxxxxxxx>
  Yang Zhang <yang.z.zhang@xxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 build-amd64-rumpuserxen                                      pass    
 build-i386-rumpuserxen                                       pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-amd64-amd64-xl-pvh-amd                                  fail    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemut-debianhvm-amd64                     pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-i386-xl-qemuu-debianhvm-amd64                     pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          fail    
 test-amd64-amd64-rumpuserxen-amd64                           fail    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-i386-xl-qemuu-win7-amd64                          fail    
 test-armhf-armhf-xl-arndale                                  pass    
 test-amd64-amd64-xl-credit2                                  pass    
 test-armhf-armhf-xl-credit2                                  pass    
 test-armhf-armhf-xl-cubietruck                               pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-i386-rumpuserxen-i386                             pass    
 test-amd64-amd64-xl-pvh-intel                                fail    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-xl-multivcpu                                pass    
 test-armhf-armhf-xl-multivcpu                                fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-rtds                                     pass    
 test-armhf-armhf-xl-rtds                                     fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     pass    
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1                     pass    
 test-amd64-amd64-xl-qemut-winxpsp3                           pass    
 test-amd64-i386-xl-qemut-winxpsp3                            pass    
 test-amd64-amd64-xl-qemuu-winxpsp3                           pass    
 test-amd64-i386-xl-qemuu-winxpsp3                            pass    

sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit 666b80f239c566283cb1b3435180d99a329d0156
Author: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
Date:   Tue Jul 21 11:13:03 2015 +0200

    dmar: device scope mem leak fix
    Release memory allocated for scope.devices dmar units on various
    failure paths and when disabling dmar. Set device count after
    sucessfull memory allocation, not before, in device scope parsing function.
    Signed-off-by: Elena Ufimtseva <elena.ufimtseva@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    # Commit 132231d10343608faf5892785a08acc500326d04
    # Date 2015-07-16 15:23:37 +0200
    # Author Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    # Committer Jan Beulich <jbeulich@xxxxxxxx>
    dmar: fix double free in error paths following c/s a8bc99b
    Several error paths would end up freeing scope->devices twice.
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: a8bc99b981c5ad773bd646f5986e616d26fb94d7
    master date: 2015-07-16 11:50:07 +0200
    master commit: 132231d10343608faf5892785a08acc500326d04
    master date: 2015-07-16 15:23:37 +0200

commit aa885a0c03ef8a2d26da0413de7d98382e496096
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Jul 21 11:12:35 2015 +0200

    make rangeset_report_ranges() report all ranges
    find_range() returns NULL when s is below the lowest range, so we have
    to use first_range() here (which is as good performance wise), or else
    no range gets reported at all in that case.
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    master commit: b1c780cd315eb4db06be3bbb5c6d80b1cabd27a9
    master date: 2015-07-15 16:11:42 +0200

commit cf423e947a9324801475956a4c3d7cc259f72e03
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Tue Jul 21 11:11:49 2015 +0200

    xen: earlycpio: Pull in latest linux earlycpio.[ch]
    AFAICT our current version does not correspond to any version in the
    Linux history. This commit resynchronised to the state in Linux
    commit 598bae70c2a8e35c8d39b610cca2b32afcf047af.
    Differences from upstream: find_cpio_data is __init, printk instead of
    This appears to fix Debian bug #785187. "Appears" because my test box
    happens to be AMD and the issue is that the (valid) cpio generated by
    the Intel ucode is not liked by the old Xen code. I've tested by
    hacking the hypervisor to look for the Intel path.
    Reported-by: Stephan Seitz <stse+debianbugs@xxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    Cc: Jan Beulich <jbeulich@xxxxxxxx>
    Cc: Stephan Seitz <stse+debianbugs@xxxxxxxxxxxxxxxxxxx>
    Cc: 785187@xxxxxxxxxxxxxxx
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 39c6664a0e6e1b4ed80660d545dff34ce41bee31
    master date: 2015-07-07 15:10:45 +0100

commit 8c166421b0af090813ad2cc691fad24784feaf1e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Jul 21 11:11:19 2015 +0200

    x86/hvmloader: avoid data corruption with xenstore reads/writes
    The functions ring_read and ring_write() have logic to try and deal with
    partial reads and writes.
    However, in all cases where the "while (len)" loop executed twice, data
    corruption would occur as the second memcpy() starts from the beginning of
    "data" again, rather than from where it got to.
    This bug manifested itself as protocol corruption when a reply header 
    the first wrap of the response ring.  However, similar corruption would also
    occur if hvmloader observed xenstored performing partial writes of the block
    in question, or if hvmloader had to wait for xenstored to make space in 
    Reported-by: Adam Kucia <djexit@xxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    master commit: bbbe7e7157a964c485fb861765be291734676932
    master date: 2015-07-07 14:39:27 +0200

commit 7b1a3be78e2a0b61f28adf8579f23e71855fe676
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 21 11:10:11 2015 +0200

    credit1: properly deal with pCPUs not in any cpupool
    Ideally, the pCPUs that are 'free', i.e., not assigned
    to any cpupool, should not be considred by the scheduler
    for load balancing or anything. In Credit1, we fail at
    this, because of how we use cpupool_scheduler_cpumask().
    In fact, for a free pCPU, cpupool_scheduler_cpumask()
    returns a pointer to cpupool_free_cpus, and hence, near
    the top of csched_load_balance():
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
         goto out;
    is false (the pCPU _is_ free!), and we therefore do not
    jump to the end right away, as we should. This, causes
    the following splat when resuming from ACPI S3 with
    pCPUs not assigned to any pool:
    (XEN) ----[ Xen-4.6-unstable  x86_64  debug=y  Tainted:    C ]----
    (XEN) ... ... ...
    (XEN) Xen call trace:
    (XEN)    [<ffff82d080122eaa>] csched_load_balance+0x213/0x794
    (XEN)    [<ffff82d08012374c>] csched_schedule+0x321/0x452
    (XEN)    [<ffff82d08012c85e>] schedule+0x12a/0x63c
    (XEN)    [<ffff82d08012fa09>] __do_softirq+0x82/0x8d
    (XEN)    [<ffff82d08012fa61>] do_softirq+0x13/0x15
    (XEN)    [<ffff82d080164780>] idle_loop+0x5b/0x6b
    (XEN) ****************************************
    (XEN) Panic on CPU 8:
    (XEN) [error_code=0000]
    (XEN) ****************************************
    The cure is:
     * use cpupool_online_cpumask(), as a better guard to the
       case when the cpu is being offlined;
     * explicitly check whether the cpu is free.
    SEDF is in a similar situation, so fix it too.
    Still in Credit1, we must make sure that free (or offline)
    CPUs are not considered "ticklable". Not doing so would impair
    the load balancing algorithm, making the scheduler think that
    it is possible to 'ask' the pCPU to pick up some work, while
    in reallity, that will never happen! Evidence of such behavior
    is shown in this trace:
     Name               CPU list
     Pool-0             0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
        0.112998198 | ||.|| -|x||-|- d0v0 runstate_change d0v4 offline->runnable
     ]  0.112998198 | ||.|| -|x||-|- d0v0   22006(2:2:6) 1 [ f ]
     ]  0.112999612 | ||.|| -|x||-|- d0v0   28004(2:8:4) 2 [ 0 4 ]
        0.113003387 | ||.|| -||||-|x d32767v15 runstate_continue d32767v15 
    where "22006(2:2:6) 1 [ f ]" means that pCPU 15, which is
    free from any pool, is tickled.
    The cure, in this case, is to filter out the free pCPUs,
    within __runq_tickle().
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    master commit: 02ea5031825d984d52eb9a982b8457e3434137f0
    master date: 2015-07-07 14:30:06 +0200

commit de8b55032455a4b591f6a853fae24e474cd3835d
Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Date:   Tue Jul 21 11:09:39 2015 +0200

    x86 / cpupool: clear the proper cpu_valid bit on pCPU teardown
    In fact, when a pCPU goes down, we want to clear its
    bit in the correct cpupool's valid mask, rather than
    always in cpupool0's one.
    Before this commit, all the pCPUs in the non-default
    pool(s) will be considered immediately valid, during
    system resume, even the one that have not been brought
    up yet. As a result, the (Credit1) scheduler will attempt
    to run its load balancing logic on them, causing the
    following Oops:
    # xl cpupool-cpu-remove Pool-0 8-15
    # xl cpupool-create name=\"Pool-1\"
    # xl cpupool-cpu-add Pool-1 8-15
    --> suspend
    --> resume
    (XEN) ----[ Xen-4.6-unstable  x86_64  debug=y  Tainted:    C ]----
    (XEN) CPU:    8
    (XEN) RIP:    e008:[<ffff82d080123078>] csched_schedule+0x4be/0xb97
    (XEN) RFLAGS: 0000000000010087   CONTEXT: hypervisor
    (XEN) rax: 80007d2f7fccb780   rbx: 0000000000000009   rcx: 0000000000000000
    (XEN) rdx: ffff82d08031ed40   rsi: ffff82d080334980   rdi: 0000000000000000
    (XEN) rbp: ffff83010000fe20   rsp: ffff83010000fd40   r8:  0000000000000004
    (XEN) r9:  0000ffff0000ffff   r10: 00ff00ff00ff00ff   r11: 0f0f0f0f0f0f0f0f
    (XEN) r12: ffff8303191ea870   r13: ffff8303226aadf0   r14: 0000000000000009
    (XEN) r15: 0000000000000008   cr0: 000000008005003b   cr4: 00000000000026f0
    (XEN) cr3: 00000000dba9d000   cr2: 0000000000000000
    (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
    (XEN) ... ... ...
    (XEN) Xen call trace:
    (XEN)    [<ffff82d080123078>] csched_schedule+0x4be/0xb97
    (XEN)    [<ffff82d08012c732>] schedule+0x12a/0x63c
    (XEN)    [<ffff82d08012f8c8>] __do_softirq+0x82/0x8d
    (XEN)    [<ffff82d08012f920>] do_softirq+0x13/0x15
    (XEN)    [<ffff82d080164791>] idle_loop+0x5b/0x6b
    (XEN) ****************************************
    (XEN) Panic on CPU 8:
    (XEN) [error_code=0000]
    (XEN) ****************************************
    The reason why the error is a #GP fault is that, without
    this commit, we try to access the per-cpu area of a not
    yet allocated and initialized pCPU.
    In fact, %rax, which is what is used as pointer, is
    80007d2f7fccb780, and we also have this:
    #define INVALID_PERCPU_AREA (0x8000000000000000L - (long)__per_cpu_start)
    Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Juergen Gross <jgross@xxxxxxxx>
    master commit: 8022b05284dea80e24813d03180788ec7277a0bd
    master date: 2015-07-07 14:29:39 +0200

commit 4b0782fe0b3aa53ca21517af1ce06bf186c24081
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Jul 21 11:08:57 2015 +0200

    x86/p2m-ept: don't unmap the EPT pagetable while it is still in use
    The call to iommu_pte_flush() between the two hunks uses &ept_entry->epte
    which is a pointer into the mapped page.
    It is eventually passed to `clflush` instruction which will suffer a 
    if the virtual mapping has fallen out of the TLB.
        (XEN) ----[ Xen-4.5.0-xs102594-d  x86_64  debug=y  Not tainted ]----
        (XEN) CPU:    7
        (XEN) RIP:    e008:[<ffff82d0801572f0>] cacheline_flush+0x4/0x9
        (XEN) Xen call trace:
        (XEN)    [<ffff82d0801572f0>] cacheline_flush+0x4/0x9
        (XEN)    [<ffff82d08014ffff>] __iommu_flush_cache+0x4a/0x6a
        (XEN)    [<ffff82d0801532e2>] iommu_pte_flush+0x2b/0xd5
        (XEN)    [<ffff82d0801f909a>] ept_set_entry+0x4bc/0x61f
        (XEN)    [<ffff82d0801f0c25>] p2m_set_entry+0xd1/0x112
        (XEN)    [<ffff82d0801f25b1>] clear_mmio_p2m_entry+0x1a0/0x200
        (XEN)    [<ffff82d0801f4aac>] unmap_mmio_regions+0x49/0x73
        (XEN)    [<ffff82d080106292>] do_domctl+0x15bd/0x1edb
        (XEN)    [<ffff82d080234fcb>] syscall_enter+0xeb/0x145
        (XEN) Pagetable walk from ffff820040004ae0:
        (XEN)  L4[0x104] = 00000008668a5063 ffffffffffffffff
        (XEN)  L3[0x001] = 00000008668a3063 ffffffffffffffff
        (XEN)  L2[0x000] = 000000086689c063 ffffffffffffffff
        (XEN)  L1[0x004] = 000000056f078063 000000000007f678
        (XEN) ****************************************
        (XEN) Panic on CPU 7:
        (XEN) [error_code=0000]
        (XEN) Faulting linear address: ffff820040004ae0
        (XEN) ****************************************
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: e4e9d2d4e76bd8fe229c124bd57fc6ba824271b3
    master date: 2015-07-07 11:37:26 +0200

commit 96289ee3250773011a1c3dcb1f5544c93fac7820
Author: Liang Li <liang.z.li@xxxxxxxxx>
Date:   Tue Jul 21 11:08:05 2015 +0200

    nested EPT: fix the handling of nested EPT
    If the host EPT entry is changed, the nested EPT should be updated.
    the current code does not do this, and it's wrong.
    I have tested this patch, the L2 guest can boot and run as normal.
    Signed-off-by: Liang Li <liang.z.li@xxxxxxxxx>
    Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    Reported-by: Tim Deegan <tim@xxxxxxx>
    Reviewed-by: Tim Deegan <tim@xxxxxxx>
    master commit: 71bb7304e7a7a35ea6df4b0cedebc35028e4c159
    master date: 2015-06-30 15:00:54 +0100
(qemu changes not included)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.