flight 127620 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-migrupgrade broken
test-amd64-i386-migrupgrade 5 host-instal
flight 127624 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127624/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64broken
test-amd64-i386-migrupgrade
flight 127682 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127682/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 558408cab99f7d422ab80ed6bf85c67bf13c5ef8
baseline version:
xen 1dfb
branch xen-unstable
xenbranch xen-unstable
job test-xtf-amd64-amd64-1
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/q
Hi,
On Mon, Dec 18, 2017 at 12:32:11PM -0500, Boris Ostrovsky wrote:
> On 12/18/2017 02:36 AM, Jan Beulich wrote:
> On 15.12.17 at 20:52, wrote:
> > +static int pcistub_device_reset(struct pci_dev *dev)
> > +{
> > + struct xen_pcibk_dev_data *dev_data;
> > + bool
flight 127627 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127627/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-pair 11 xen-boot/dst_host fail in 127601 pass in 127627
test-amd64-i386-xl-shadow
flight 127636 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 127464
Tests which did not
flight 127632 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127632/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 broken
Tests which are f
flight 127637 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR.
vs. 127454
Tests whi
This run is configured for baseline tests only.
flight 75232 xen-4.7-testing real [real]
http://osstest.xensource.com/osstest/logs/75232/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
On Thu, Sep 13, 2018 at 03:47:49PM -0400, Boris Ostrovsky wrote:
> From: "Dr. Greg Wettstein"
>
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in commit ccc9d90a9a8b
> ("xenbus_client: Extend interface to support multi-page ring").
On Thu, Sep 13, 2018 at 05:25:51PM -0400, Boris Ostrovsky wrote:
> From: "Dr. Greg Wettstein"
>
> Functionality of the xen-tpmfront driver was lost secondary to
> the introduction of xenbus multi-page support in commit ccc9d90a9a8b
> ("xenbus_client: Extend interface to support multi-page ring").
On 9/14/18 3:34 AM, Dongli Zhang wrote:
+
+struct mtwatch_info {
+ /*
+* The mtwatch_domain is put on both a hash table and a list.
+* domain_list is used to optimize xenbus_watch un-registration.
+*
+* The mtwatch_domain is removed from domain_hash (with
Hi all,
I have recently upgraded from Xen 4.8.3 to 4.8.4 and now no VM's will start
as they fail with the following error message:
-
Parsing config from /etc/xen/config/Windows_Server.cfg
libxl: error: libxl_dm.c:2189:device_model_spawn_outcome: domain 4 device
model: spawn failed (rc=-3)
On 9/14/18 3:34 AM, Dongli Zhang wrote:
+
+/* Running in the context of default xenwatch kthread. */
+void mtwatch_create_domain(domid_t domid)
+{
+ struct mtwatch_domain *domain;
+
+ if (!domid) {
+ pr_err("Default xenwatch thread is for dom0\n");
+ ret
flight 127639 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 broken
test-amd64-amd64-xl-qemuu-debianhvm-a
Hi,
On 09/06/2018 08:25 PM, Andrew Cooper wrote:
The vcpu functions are far less consistent than the domain side of things, and
in particular, has vcpu_destroy() for architecture specific functionality.
Perform the following renames:
* alloc_vcpu => vcpu_create
* vcpu_initialise =>
Hi Boris,
On 09/17/2018 04:17 AM, Boris Ostrovsky wrote:
>
>
> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>
>> +
>> +struct mtwatch_info {
>> +/*
>> + * The mtwatch_domain is put on both a hash table and a list.
>> + * domain_list is used to optimize xenbus_watch un-registration.
>> +
Hi Boris,
On 09/17/2018 05:20 AM, Boris Ostrovsky wrote:
>
>
> On 9/14/18 3:34 AM, Dongli Zhang wrote:
>>
>> +
>> +/* Running in the context of default xenwatch kthread. */
>> +void mtwatch_create_domain(domid_t domid)
>> +{
>> +struct mtwatch_domain *domain;
>> +
>> +if (!domid) {
>> +
flight 127646 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 broken
build-i386-rumprun6 rumpru
20 matches
Mail list logo
