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

[Xen-devel] [xen-unstable-smoke test] 109890: regressions - trouble: blocked/broken/fail/pass



flight 109890 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/109890/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   5 xen-build                fail REGR. vs. 109864

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  8ac9a25b26841b539fd7f345fc87a4142a86adb3
baseline version:
 xen                  7b5cb2f18e9b98f930f78b64a0f0a3b45139aa53

Last test of basis   109864  2017-05-30 19:02:36 Z    0 days
Testing same since   109887  2017-05-31 07:02:17 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Luwei Kang <luwei.kang@xxxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Swapnil Paratey <swapnil.paratey@xxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>
  Zhang Bo <oscar.zhangbo@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-arm64-arm64-xl-xsm                                      broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     pass    
 test-amd64-amd64-libvirt                                     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
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
    http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 8ac9a25b26841b539fd7f345fc87a4142a86adb3
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Wed May 31 08:47:57 2017 +0200

    docs: remove PVHv1 document
    
    The current misc/pvh.markdown document refers to PVHv1, remove it to
    avoid confusion with PVHv2 since the PVHv1 code has already been
    removed.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 2d08fb32bc3d252046748e908bafc1bf6376313e
Author: Luwei Kang <luwei.kang@xxxxxxxxx>
Date:   Wed May 31 08:41:43 2017 +0200

    x86/vpmu: add cpu hot unplug notifier for vpmu
    
    Currently, Hot unplug a physical CPU with vpmu enabled may cause
    system hang due to send a remote call to an offlined pCPU. This
    patch add a cpu hot unplug notifer to save vpmu context before
    cpu offline.
    
    Consider one scenario, hot unplug pCPU N with vpmu enabled.
    The vcpu which running on this pCPU will be switch to other
    online cpu. A remote call will be send to pCPU N to save the
    vpmu context before loading the vpmu context on this pCPU.
    System will hang in function on_select_cpus() because of that
    pCPU is offlined and can not do any respond.
    
    The purpose of add a VPMU_CONTEXT_LOADED check in vpmu_arch_destroy()
    before send a remote call to save vpmu contex is:
    a. when a vpmu context has been loaded in a remote pCPU, make a
       remote call to save the vpmu contex and stop counters is necessary.
    b. VPMU_CONTEXT_LOADED flag will be reset if a pCPU is offlined.
       this check will prevent send a remote call to an offlined pCPU.
    
    Signed-off-by: Luwei Kang <luwei.kang@xxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit 02dc2aa7bf54602cf2d752a2af9fa38cee870fc8
Author: Zhang Bo <oscar.zhangbo@xxxxxxxxxx>
Date:   Wed May 31 08:40:44 2017 +0200

    acpi: enlarge NUM_FIXMAP_ACPI_PAGES to support larger scale boards
    
    In acpi_tb_verify_table()->__acpi_map_table(), it suppose all ACPI tables
    may not exceed 4 pages, the tables includes SRAT/APIC/ERST etc.
    Please note that the table DSDT is not mapped through
    acpi_tb_verify_table(), thus we don't care its size although it's usually
    the largest table among all the ACPI tables. Then the biggest table we
    concern is SRAT.
    As we know, the size of SRAT if affected by both CPU number and memory
    slot number, each CPU costs 24B, and each memory slot costs 40B.
    
    Please note: even when SRAT table is within 4 pages, eg. 14128B, in
    __acpi_map_table(), it maps pages to get the table. suppose the start
    address is near the end of the first page:
    
           1000B    4096B         4096B          4096B      840B
           |___|_____________|______________|______________|____|
    
    although the total page is within 4 pages , but it may be in fact across 5
    pages, as shown above. Thus the NUM_FIXMAP_ACPI_PAGES should be much
    larger nowadays. If not, xen would wrongly thinks no NUMA configuration
    could be found as that it could not get SRAT table.
    
    Thus, we make NUM_FIXMAP_ACPI_PAGES much larger, to 64(256KB). it's
    calculated for that the theoretical largest CPU number on main Linux
    distros is about 8192, and memory slots number should be within 1000,
    that's 24B*8192+40B*1000 = 236608B. Meanwhile, because IOREMAP_VIRT_*
    region is 16GB, thus I think extending it to 256KB is safe enough.
    
    Of course, there's much more work to do to support large scale boards of
    that many(8192) CPUs and 1000 memory slots. We just make life easier for
    boards with serveral hundreds of CPUs and serveral TBs of memory.
    
    Signed-off-by: Zhang Bo <oscar.zhangbo@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit a91252ff0d219d801f2dc947511c1755fe5b05fe
Author: Swapnil Paratey <swapnil.paratey@xxxxxxx>
Date:   Wed May 31 08:40:15 2017 +0200

    ns16550: add support for UART parameters to be specifed with name-value 
pairs
    
    Add name=value parsing options for com1 and com2 to add flexibility
    in setting register values for MMIO UART devices.
    
    Maintain backward compatibility with previous positional parameter
    specfications.
    
    eg. com1=115200,8n1,0x3f8,4
    eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
    eg. com1=baud=115200,parity=n,reg_width=4,reg_shift=2,irq=4
    
    Signed-off-by: Swapnil Paratey <swapnil.paratey@xxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit d7594d553b10e74a0cbe15a157baac1aae1d3acd
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Wed May 31 08:39:47 2017 +0200

    x86/mmcfg: set pci_mmcfg_config_num to 0 on error path
    
    One error path of acpi_parse_mcfg doesn't set pci_mmcfg_config_num to zero, 
fix
    this.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit d781dbcb80e598d38d8df532fe987e770ed76d62
Author: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
Date:   Wed May 31 08:39:22 2017 +0200

    x86/mce: make 'found_error' and 'mce_fatal_cpus' private to 
mcheck_cmn_handler()
    
    mcheck_cmn_handler() is the only user of 'found_error' and
    'mce_fatal_cpus'.
    
    Signed-off-by: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 1403d5d9a6ca3560aa38308c437d254b0c9bc3af
Author: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
Date:   Wed May 31 08:38:21 2017 +0200

    x86/mce: make mce barriers private to their users
    
    Each of current mce barriers is actually used by only one function, so
    move their definitions into their users. A static mce barrier initializer
    is introduced so we can move the initialization of above mce barriers
    to their definitions.
    
    Signed-off-by: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)

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

 


Rackspace

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