flight 22283 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/22283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 xen-build fail REGR. vs. 22278
build-armhf-pvops 4 kernel-build fail REGR. vs. 22278
build-amd64-pvops 4 kernel-build fail REGR. vs. 22278
build-amd64 4 xen-build fail REGR. vs. 22278
build-amd64-oldkern 4 xen-build fail REGR. vs. 22278
Tests which did not succeed, but are not blocking:
test-amd64-i386-freebsd10-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
test-amd64-i386-freebsd10-i386 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a
test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemut-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a
test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a
test-armhf-armhf-xl 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-qemut-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-i386-xend-qemut-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-winxpsp3 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen 71952bfcbe9187765cf4010b1479af86def4fb1f
baseline version:
xen 4b07b3cbf29f66da6090d52e75b5fdae592c6441
------------------------------------------------------------
People who touched revisions under test:
Anthony PERARD <anthony.perard@citrix.com>
Daniel Kiper <daniel.kiper@oracle.com>
Eddie Dong <eddie.dong@intel.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@linaro.org>
Keir Fraser <keir@xen.org>
Lan Yixun (dlan) <dennis.yxun@gmail.com>
Nathan Studer <nate.studer@dornerworks.com>
Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
------------------------------------------------------------
jobs:
build-amd64 fail
build-armhf fail
build-i386 pass
build-amd64-oldkern fail
build-i386-oldkern pass
build-amd64-pvops fail
build-armhf-pvops fail
build-i386-pvops pass
test-amd64-amd64-xl blocked
test-armhf-armhf-xl blocked
test-amd64-i386-xl blocked
test-amd64-i386-rhel6hvm-amd blocked
test-amd64-i386-qemut-rhel6hvm-amd blocked
test-amd64-i386-qemuu-rhel6hvm-amd blocked
test-amd64-i386-freebsd10-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 blocked
test-amd64-i386-xl-qemut-win7-amd64 blocked
test-amd64-amd64-xl-qemuu-win7-amd64 blocked
test-amd64-amd64-xl-win7-amd64 blocked
test-amd64-i386-xl-win7-amd64 blocked
test-amd64-i386-xl-credit2 blocked
test-amd64-i386-freebsd10-i386 blocked
test-amd64-amd64-xl-pcipt-intel blocked
test-amd64-i386-rhel6hvm-intel blocked
test-amd64-i386-qemut-rhel6hvm-intel blocked
test-amd64-i386-qemuu-rhel6hvm-intel blocked
test-amd64-i386-xl-multivcpu blocked
test-amd64-amd64-pair blocked
test-amd64-i386-pair blocked
test-amd64-amd64-xl-sedf-pin blocked
test-amd64-amd64-pv blocked
test-amd64-i386-pv blocked
test-amd64-amd64-xl-sedf blocked
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked
test-amd64-i386-xl-winxpsp3-vcpus1 blocked
test-amd64-i386-xend-qemut-winxpsp3 blocked
test-amd64-amd64-xl-qemut-winxpsp3 blocked
test-amd64-amd64-xl-qemuu-winxpsp3 blocked
test-amd64-i386-xend-winxpsp3 blocked
test-amd64-amd64-xl-winxpsp3 blocked
------------------------------------------------------------
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.
------------------------------------------------------------
commit 71952bfcbe9187765cf4010b1479af86def4fb1f
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Dec 4 14:54:21 2013 +0000
xen: arm: Enable 1:1 workaround by default
I was just about to send out patches adding the 1:1 workaround to vexpress
(the foundation model is a vexpress platfrom with DMA) and sunxi.
That would have meant that all platforms now implement the quirk. Instead
lets
just make it the default and remove the quirk.
In the future this will likely be set based on the presence absence of an
IOMMU, perhaps with additional overrides by the platform.
This results in some dead code in domain_build for dealing with the non-1:1
case. This is deliberate and is left in anticipation of IOMMU support in
4.5.
PLATFORM_QUIRK_GIC_64K_STRIDE is renumbered as a side effect of this change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
commit ca5690565784caa53b9889f8539c2dd9b375e419
Merge: c04fbf5... 747fb88...
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Dec 4 14:51:57 2013 +0000
Merge branch ''staging'' of
ssh://xenbits.xen.org/home/xen/git/xen into staging
commit 747fb88881b0c448fa99a94fba3a492066df248a
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed Dec 4 14:46:19 2013 +0000
QEMU_TAG update
commit c04fbf58558de544b96c861bb88293524fa30afc
Author: Dennis Lan (dlan) <dennis.yxun@gmail.com>
Date: Wed Dec 4 14:37:25 2013 +0000
xen: arm64: clear boot_first instead of boot_pgtable twice
Signed-off-by: Lan Yixun (dlan) <dennis.yxun@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit fda8904bf3d149296a3dd8d3e7fc835d91b9828e
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu Nov 28 19:44:50 2013 +0000
Update QEMU_UPSTREAM_REVISION
Changing to master, otherwise we don''t get the last updates.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 2cebe22e6924439535cbf4a9f82a7d9d30c8f9c7
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date: Mon Dec 2 20:13:03 2013 +0100
libxenctrl: Fix xc_interface_close() crash if it gets NULL as an argument
xc_interface_close() crashes if it gets NULL as an argument. However,
it just calls xc_interface_close_common() which is called by many
others functions. It means that they are also vulnerable. So fix above
mentioned issue by adding NULL check in xc_interface_close_common().
This way we fix similar issue in other functions which calls
xc_interface_close_common() too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 17d34efd6751f93bec943ccc8f5b8c56c8fbb483
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Tue Dec 3 15:13:36 2013 +0000
xen: arm: TCR_EL1 is 64-bit on arm64
Storing it in a 32-bit variable in struct arch_vcpu caused breakage over
context switch.
There were also several other places which stored this as the 32-bit value.
Update them all.
The "struct vcpu_guest_context" case needs special consideration.
This struct
is in theory is exposed to guests, via the VCPUOP_initialise hypercall.
However as discussed in
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00912.html this
isn''t
really a guest visible interface since ARM uses PSCI for VCPU bringup
(VCPUOP_initialise simply isn''t available) The other users of this
interface
are the domctls, which are not a stable API. Therefore while fixing the
ttbcr
size also surround the struct in ifdefs to restrict the struct to the
hypervisor and the tools only (omitting the extra complexity of renaming as
I
suggested in the referenced thread).
NB TCR_EL1 on arm64 is known as TTBCR on arm32, hence the apparent naming
inconsistencies.
Spotted-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Cc: Anup Patel <anup.patel@linaro.org>
Cc: patches@linaro.org
Cc: patches@apm.com
commit 375c911acc373b4765c0b6e53203e37ae4eb3745
Merge: 81dcaaa... 9f0c658...
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Wed Dec 4 14:29:39 2013 +0000
Merge branch ''staging'' of
ssh://xenbits.xen.org/home/xen/git/xen into staging
commit 81dcaaa97a21cb397cd326fdcb8f9953ea23ceff
Author: Nathan Studer <nate.studer@dornerworks.com>
Date: Tue Dec 3 17:24:27 2013 -0500
arinc: Add poolid parameter to scheduler get/set functions
Signed-off-by: Nathan Studer <nate.studer@dornerworks.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 9f0c658baedcd0f3f71c35b54965e440ffef0e45
Author: Nathan Studer <nate.studer@dornerworks.com>
Date: Wed Dec 4 13:29:00 2013 +0100
arinc: add cpu-pool support to scheduler
1. Remove the restriction that dom0 must be in the schedule, since dom-0
may
not belong to the scheduler''s pool.
2. Add a schedule entry for each of dom-0''s vcpus as they are
created.
3. Add code to deal with empty schedules in the do_schedule function.
4. Call the correct idle task for the pcpu on which the scheduling decision
is being made in do_schedule.
5. Add code to prevent migration of a vcpu.
6. Implement a proper cpu_pick function, which prefers the current
processor.
7. Add a scheduler lock to protect access to global variables from multiple
PCPUs.
These changes do not implement arinc653 multicore. Since the schedule only
supports 1 vcpu entry per slot, even if the vcpus of a domain are run on
multiple pcpus, the scheduler will essentially serialize their execution.
Signed-off-by: Nathan Studer <nate.studer@dornerworks.com>
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
commit dc37e0bfffc673f4bdce1d69ad86098bfb0ab531
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date: Wed Dec 4 13:26:37 2013 +0100
x86: fix early boot command line parsing
There is no reliable way to encode NUL character as a character so encode
it as a number. Read:
http://sourceware.org/binutils/docs/as/Characters.html.
Octal and hex encoding do not work on at least one system (GNU assembler
version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian)
2.22).
Without this fix e.g. no-real-mode option at the end of xen.gz command line
is not detected.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
commit e1978480c76e36bc22ec12657121ac91d08aca6b
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Dec 4 13:23:27 2013 +0100
nested VMX: fix I/O port exit emulation
For multi-byte operations all affected ports'' bits in the bitmap
need
to be checked, not just the first port''s one.
Reported-by: Matthew Daley <mattd@bugfuzz.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
(qemu changes not included)
On Wed, 2013-12-04 at 19:13 +0000, xen.org wrote:> flight 22283 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/22283/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-armhf 4 xen-build fail REGR. vs. 22278 > build-armhf-pvops 4 kernel-build fail REGR. vs. 22278 > build-amd64-pvops 4 kernel-build fail REGR. vs. 22278 > build-amd64 4 xen-build fail REGR. vs. 22278 > build-amd64-oldkern 4 xen-build fail REGR. vs. 22278The amd64 ones are all: Warning: Permanently added ''10.80.249.149'' (RSA) to the list of known hosts. 2013-12-04 17:47:08 Z command timed out [60]: ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o UserKnownHostsFile=tmp/t.known_hosts_22283.build-amd64 osstest@10.80.249.149 rm -rf /home/osstest/build.22283.build-amd64 && mkdir /home/osstest/build.22283.build-amd64 status (timed out) at Osstest/TestSupport.pm line 379. Same IP in every case. Looks like gall-mite had an episode: Dec 4 16:21:31.216425 gall-mite login: [ 481.242300] INFO: task kjournald:370 blocked for more than 120 seconds. Dec 4 16:29:06.956848 [ 481.248975] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Dec 4 16:29:06.964750 [ 481.256985] INFO: task rs:main Q:Reg:20255 blocked for more than 120 seconds. The armhf ones are: 2013-12-04 17:45:01 Z executing ssh ... osstest@10.80.246.74 rm -rf /local/scratch/osstest/osstest/build.22283.build-armhf && mkdir /local/scratch/osstest/osstest/build.22283.build-armhf Warning: Permanently added ''10.80.246.74'' (RSA) to the list of known hosts. mkdir: cannot create directory `/local/scratch/osstest/osstest/build.22283.build-armhf'': No such file or directory 2013-12-04 17:45:02 Z command nonzero waitstatus 256: ssh -o StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 -o PasswordAuthentication=no -o ChallengeResponseAuthentication=no -o UserKnownHostsFile=tmp/t.known_hosts_22283.build-armhf osstest@10.80.246.74 rm -rf /local/scratch/osstest/osstest/build.22283.build-armhf && mkdir /local/scratch/osstest/osstest/build.22283.build-armhf status 256 at Osstest/TestSupport.pm line 379. The host is army and: $ ls /local/scratch/osstest/osstest/ build.22298.build-armhf/ build.22299.build-armhf/ build.22298.build-armhf-pvops/ build.22299.build-armhf-pvops/ plus sudo su -c ''mkdir /local/scratch/osstest/osstest/build.22283.build-armhf'' osstest works. so I''m a bit perplexed by this one. Ian.
On gio, 2013-12-05 at 09:31 +0000, Ian Campbell wrote:> On Wed, 2013-12-04 at 19:13 +0000, xen.org wrote:> 2013-12-04 17:45:01 Z executing ssh ... osstest@10.80.246.74 rm -rf /local/scratch/osstest/osstest/build.22283.build-armhf && mkdir /local/scratch/osstest/osstest/build.22283.build-armhf > Warning: Permanently added ''10.80.246.74'' (RSA) to the list of known hosts. > mkdir: cannot create directory `/local/scratch/osstest/osstest/build.22283.build-armhf'': No such file or directory >So, about these things... Why OSSTest does no create this (and other) dirs himself if they''re not present? Is that intentional? If yes, is that a form of safety check, a way to tell the user "hey, perhaps you have something wrong in your config file"? If that is the case then, given a bit of attention is necessary when deploying it anyway, I don''t think this buys us that much more "user friendliness", while it certainly is something annoying. Personally, I think it should just go ahead... Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2013-12-05 at 13:19 +0100, Dario Faggioli wrote:> On gio, 2013-12-05 at 09:31 +0000, Ian Campbell wrote: > > On Wed, 2013-12-04 at 19:13 +0000, xen.org wrote: > > > 2013-12-04 17:45:01 Z executing ssh ... osstest@10.80.246.74 rm -rf /local/scratch/osstest/osstest/build.22283.build-armhf && mkdir /local/scratch/osstest/osstest/build.22283.build-armhf > > Warning: Permanently added ''10.80.246.74'' (RSA) to the list of known hosts. > > mkdir: cannot create directory `/local/scratch/osstest/osstest/build.22283.build-armhf'': No such file or directory > > > So, about these things... Why OSSTest does no create this (and other) > dirs himself if they''re not present?In the general case, e.g. tmp and logs this is IMHO a bug (or several bugs) in osstest. In this particular case /local/scratch/osstest is the osstest users $HOME and I think osstest should be entitled to assume that exists. When we disabled builds on this machine I incorrectly removed this dir forgetting that it was $HOME and not just a scratch dir (which arises because osstest is a local user and not a not a global NIS user, and army uses NIS/autofs for /home)> If that is the case then, given a bit of attention is necessary when > deploying it anyway, I don''t think this buys us that much more "user > friendliness", while it certainly is something annoying. Personally, I > think it should just go ahead...Yes, for all cases apart from this one I think patches to add a suitable mkdir would be appreciated. Ian.
On gio, 2013-12-05 at 12:28 +0000, Ian Campbell wrote:> On Thu, 2013-12-05 at 13:19 +0100, Dario Faggioli wrote: > > On gio, 2013-12-05 at 09:31 +0000, Ian Campbell wrote: > > > On Wed, 2013-12-04 at 19:13 +0000, xen.org wrote: > > > > > 2013-12-04 17:45:01 Z executing ssh ... osstest@10.80.246.74 rm -rf /local/scratch/osstest/osstest/build.22283.build-armhf && mkdir /local/scratch/osstest/osstest/build.22283.build-armhf > > > Warning: Permanently added ''10.80.246.74'' (RSA) to the list of known hosts. > > > mkdir: cannot create directory `/local/scratch/osstest/osstest/build.22283.build-armhf'': No such file or directory > > > > > So, about these things... Why OSSTest does no create this (and other) > > dirs himself if they''re not present? > > In the general case, e.g. tmp and logs this is IMHO a bug (or several > bugs) in osstest. >Ok.> In this particular case /local/scratch/osstest is the osstest users > $HOME and I think osstest should be entitled to assume that exists. >Right... I think I missed that part because I mostly look at test rather than build failure reports.> When we disabled builds on this machine I incorrectly removed this dir > forgetting that it was $HOME and not just a scratch dir (which arises > because osstest is a local user and not a not a global NIS user, and > army uses NIS/autofs for /home) >Mmm... interesting. I tried to do something similar on another box, but didn''t manage to get to the end of it. I''ll contact you either offline or in a different thread about that. :-)> > If that is the case then, given a bit of attention is necessary when > > deploying it anyway, I don''t think this buys us that much more "user > > friendliness", while it certainly is something annoying. Personally, I > > think it should just go ahead... > > Yes, for all cases apart from this one I think patches to add a suitable > mkdir would be appreciated. >Sure, I''ll look into this. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 22283:
regressions - FAIL"):> In this particular case /local/scratch/osstest is the osstest users
> $HOME and I think osstest should be entitled to assume that exists.
In fact /local/scratch/osstest still existed. What didn''t exist was
/local/scratch/osstest/osstest. osstest doesn''t assume that the whole
of the ~ for the user it is told to use is its own playground.
Arguably it ought to create ~/osstest on demand.
Ian.