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

[Xen-devel] [xen-unstable test] 21293: regressions - FAIL

flight 21293 xen-unstable real [real]

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 21268
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install     fail REGR. vs. 21268
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 21268
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 21268
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 21268
 test-amd64-i386-xl-qemut-win7-amd64  7 windows-install    fail REGR. vs. 21268

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass

version targeted for testing:
 xen                  8b2c441a1b53a43a38b3c517e28f239da3349872
baseline version:
 xen                  8f5a051507537aa01995dd0a97a50d1c96fcc2b4

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Jun Nakajima <jun.nakajima@xxxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Matthew Daley <mattjd@xxxxxxxxx>
  Thomas Sanders <thomas.sanders@xxxxxxxxxx>
  Yang Zhang <yang.z.zhang@xxxxxxxxx>

 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 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-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-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-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

Test harness code can be found at

Not pushing.

commit 8b2c441a1b53a43a38b3c517e28f239da3349872
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Tue Oct 29 15:45:53 2013 +0000

    tools: xenstored: if the reply is too big then send E2BIG error
    This fixes the issue for both C and ocaml xenstored, however only the ocaml
    xenstored is vulnerable in its default configuration.
    Adding a new error appears to be safe, since bit libxenstore and the Linux
    driver at least treat an unknown error code as EINVAL.
    This is XSA-72 / CVE-2013-4416.
    Original ocaml patch by Jerome Maloberti <jerome.maloberti@xxxxxxxxxx>
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Signed-off-by: Thomas Sanders <thomas.sanders@xxxxxxxxxx>

commit 41a0cc9e26160a89245c9ba3233e3f70bf9cd4b4
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Oct 29 09:57:14 2013 +0100

    fix locking in cpu_disable_scheduler()
    So commit eedd6039 ("scheduler: adjust internal locking interface")
    uncovered - by now using proper spin lock constructs - a bug after all:
    When bringing down a CPU, cpu_disable_scheduler() gets called with
    interrupts disabled, and hence the use of vcpu_schedule_lock_irq() was
    never really correct (i.e. the caller ended up with interrupts enabled
    despite having disabled them explicitly).
    Fixing this however surfaced another problem: The call path
    vcpu_migrate() -> evtchn_move_pirqs() wants to acquire the event lock,
    which however is a non-IRQ-safe once, and hence check_lock() doesn't
    like this lock to be acquired when interrupts are already off. As we're
    in stop-machine context here, getting things wrong wrt interrupt state
    management during lock acquire/release is out of question though, so
    the simple solution to this appears to be to just suppress spin lock
    debugging for the period of time while the stop machine callback gets
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>

commit c9efe34c119418a5ac776e5d91aeefcce4576518
Author: Yang Zhang <yang.z.zhang@xxxxxxxxx>
Date:   Tue Oct 29 09:55:23 2013 +0100

    VMX: Eliminate cr3 store/load vmexit when UG enabled
    With the feature of unrestricted guest, Xen should not cause
    vmexits for cr3 accesses in non-paging mode.
    Signed-off-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>
    Acked-by: Jun Nakajima <jun.nakajima@xxxxxxxxx>

commit 2cd1f418feb215c379b6737576b53bba6f70c1a6
Author: Matthew Daley <mattjd@xxxxxxxxx>
Date:   Sun Oct 27 19:49:14 2013 +1300

    xl: don't emit misleading daemon pid message
    After creating a domain, xl forks off a process to handle domain events
    (shutdown, disk eject, ...). It prints out the pid of the process
    created by the fork to stdout. However, the newly forked process soon
    after calls daemon(), which itself forks once more (and exit()s the
    original process). This means that the pid printed out is not the pid of
    the actual process which remains in the background after all is said and
    done, instead it is the pid of the transient process that exists between
    xl's fork() and the fork'd process's daemon() call.
    We could resolve this by printing the correct pid, ie. by open-coding
    daemon() (we already do most of the heavy lifting it does ourselves by
    fiddling with the standard fds). However, since no-one seems to be
    complaining about the misleading message to begin with, and since it
    seems like a pointless message anyway, just remove it outright instead.
    Signed-off-by: Matthew Daley <mattjd@xxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

commit 35e874b1d5d56dd2098313364b879c637fa56844
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Fri Oct 25 08:47:35 2013 +0100

    libxenstore: Use PTHREAD_STACK_MIN
    The existing value of 16K is smaller than the arm64 minimum stack size, 
    is 128K. PTHREAD_STACK_MIN appears to be standard
    Consindered setting a lower bound but the stack requirements of the watcher
    thread are pretty minimal (tens of bytes from the looks of it) and unlikely 
    blow PTHREAD_STACK_MIN on any useful platform.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

commit dc19afbad9319b00474951d4218a37c072a6570b
Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date:   Fri Oct 25 08:47:24 2013 +0100

    libxl: remove spurious newline from LOG() message
    The macro already includes this.
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

commit e6564c634863680f6541e07ce2f77f17d45ce52e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Oct 28 11:30:35 2013 +0000

    libelf: improve errors in elf_xen_note_check()
    I recently debugged an isolated failure to boot, with no information other
    than the logs.
    The "Will only load images built for the generic loader or Linux images"
    string was missing a newline, leading to the subsequent error being appended
    to this line, rather than having its own line with correctly identified
    Furthermore, error messages which state "param containing $FOO is not $BAR" 
    fairly useless for debugging without identifying which bad $FOO caused the
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    CC: Keir Fraser <keir@xxxxxxx>
    CC: Jan Beulich <JBeulich@xxxxxxxx>
    CC: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
(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®.