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

[Xen-devel] [xen-4.2-testing test] 13920: regressions - FAIL



flight 13920 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13920/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv           9 guest-start               fail REGR. vs. 13912

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore            fail   never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-xl-qemuu-winxpsp3  9 guest-localmigrate         fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64  9 guest-localmigrate     fail never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 guest-localmigrate       fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  a69c8e5c4afc
baseline version:
 xen                  ca3e8190a72c

------------------------------------------------------------
People who touched revisions under test:
  Ben Guthro <ben@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          fail    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-i386-i386-xl-qemuu-winxpsp3                             fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

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


Not pushing.

------------------------------------------------------------
changeset:   25871:a69c8e5c4afc
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Oct 04 10:16:20 2012 +0200
    
    x86/ucode: fix Intel case of resume handling on boot CPU
    
    Checking the stored version doesn't tell us anything about the need to
    apply the update (during resume, what is stored doesn't necessarily
    match what is loaded).
    
    Note that the check can be removed altogether because once switched to
    use what was read from the CPU (uci->cpu_sig.rev, as used in the
    subsequent pr_debug()), it would become redundant with the checks that
    lead to microcode_update_match() returning the indication that an
    update should be applied.
    
    Note further that this was not an issue on APs since they start with
    uci->mc.mc_intel being NULL.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Ben Guthro <ben@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25965:4496d56c68a0
    xen-unstable date: Fri Sep 28 07:28:11 UTC 2012
    
    
changeset:   25870:648c99c230ff
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Oct 04 10:15:16 2012 +0200
    
    x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()
    
    There are two greater-than-zero checks for the old vector retrieved,
    which don't work when a negative value got stashed into the respective
    arch_irq_desc field. The effect of this was that for interrupts that
    are intended to get their affinity adjusted the first time before the
    first interrupt occurs, the affinity change would fail, because the
    original vector assignment would have caused the move_in_progress flag
    to get set (which causes subsequent re-assignments to fail until it
    gets cleared, which only happens from the ->ack() actor, i.e. when an
    interrupt actually occurred).
    
    This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
    changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25962:41f523f1b5e5
    xen-unstable date: Fri Sep 28 07:23:34 UTC 2012
    
    
changeset:   25869:051661b76ade
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Oct 04 10:14:44 2012 +0200
    
    x86/HPET: don't disable interrupt delivery right after setting it up
    
    We shouldn't clear HPET_TN_FSB right after we (indirectly, via
    request_irq()) enabled it for the channels we intend to use for
    broadcasts.
    
    This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25961:6a5812129094
    xen-unstable date: Fri Sep 28 07:22:14 UTC 2012
    
    
changeset:   25868:b4bda6995bc1
user:        Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
date:        Thu Oct 04 10:13:55 2012 +0200
    
    x86: check remote MMIO remap permissions
    
    When a domain is mapping pages from a different pg_owner domain, the
    iomem_access checks are currently only applied to the pg_owner domain,
    potentially allowing a domain with a more restrictive iomem_access
    policy to have the pages mapped into its page tables. To catch this,
    also check the owner of the page tables. The current domain does not
    need to be checked because the ability to manipulate a domain's page
    tables implies full access to the target domain, so checking that
    domain's permission is sufficient.
    
    Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    xen-unstable changeset: 25952:8278d7d8fa48
    xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
    
    
changeset:   25867:b0aed9cadf10
user:        Ben Guthro <ben@xxxxxxxxxx>
date:        Thu Oct 04 10:12:43 2012 +0200
    
    x86/S3: add cache flush on secondary CPUs before going to sleep
    
    Secondary CPUs, between doing their final memory writes (particularly
    updating cpu_initialized) and getting a subsequent INIT, may not write
    back all modified data. The INIT itself then causes those modifications
    to be lost, so in the cpu_initialized case the CPU would find itself
    already initialized, (intentionally) entering an infinite loop instead
    of actually coming online.
    
    Signed-off-by: Ben Guthro <ben@xxxxxxxxxx>
    
    Make acpi_dead_idle() call default_dead_idle() rather than duplicating
    the logic there.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25940:c8d65d91a6f2
    xen-unstable date: Tue Sep 25 06:38:14 UTC 2012
    
    
changeset:   25866:ffabc1ebd913
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Oct 04 10:11:11 2012 +0200
    
    x86: tighten checks in XEN_DOMCTL_memory_mapping handler
    
    Properly checking the MFN implies knowing the physical address width
    supported by the platform, so to obtain this consistently the
    respective code gets moved out of the MTRR subdir.
    
    Btw., the model specific workaround in that code is likely unnecessary
    - I believe those CPU models don't support 64-bit mode. But I wasn't
    able to formally verify this, so I preferred to retain that code for
    now.
    
    But domctl code here also was lacking other error checks (as was,
    looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
    Besides adding the missing checks, printing is also added for the case
    where revoking access permissions didn't work (as that may have
    implications for the host operator, e.g. wanting to not pass through
    affected devices to another guest until the one previously using them
    did actually die).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25931:149805919569
    xen-unstable date: Thu Sep 20 07:21:53 UTC 2012
    
    
changeset:   25865:63823a6785fc
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Thu Oct 04 10:10:23 2012 +0200
    
    x86: properly check XEN_DOMCTL_ioport_mapping arguments for invalid range
    
    In particular, the case of "np" being a very large value wasn't handled
    correctly. The range start checks also were off by one (except that in
    practice, when "np" is properly range checked, this would still have
    been caught by the range end checks).
    
    Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    xen-unstable changeset: 25927:3e3959413b2f
    xen-unstable date: Wed Sep 19 07:27:55 UTC 2012
    
    
changeset:   25864:ca3e8190a72c
user:        Ian Campbell <ian.campbell@xxxxxxxxxx>
date:        Tue Oct 02 16:02:10 2012 +0100
    
    tools: bump SONAMEs for changes during 4.2 development cycle.
    
    We mostly did this as we went along, only a couple of minor number
    bumps were missed http://marc.info/?l=xen-devel&m=134366054929255&w=2:
     - Bumped libxl from 1.0.0 -> 1.0.1
     - Bumped libxenstore from 3.0.1 -> 3.0.2
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    
    xen-unstable changeset: 25943:0a64f1a3f72c
    Backport-requested-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
(qemu changes not included)

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


 


Rackspace

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