As a preparation for per-cpu buffers do a little refactoring of the
debugtrace data: put the needed buffer admin data into the buffer as
it will be needed for each buffer.
While at it switch debugtrace_send_to_console and debugtrace_used to
bool and delete an empty line.
Signed-off-by: Juergen Gr
Another debugtrace enhancement I needed for core scheduling debugging.
Juergen Gross (3):
xen: move debugtrace coding to common/debugtrace.c
xen: refactor debugtrace data
xen: add per-cpu buffer option to debugtrace
docs/misc/xen-command-line.pandoc | 7 +-
xen/common/Makefile
debugtrace is normally writing trace entries into a single trace
buffer. There are cases where this is not optimal, e.g. when hunting
a bug which requires writing lots of trace entries and one cpu is
stuck. This will result in other cpus filling the trace buffer and
finally overwriting the interest
Instead of living in drivers/char/console.c move the debugtrace
related coding to a new file common/debugtrace.c
Signed-off-by: Juergen Gross
---
xen/common/Makefile| 1 +
xen/common/debugtrace.c| 177 +
xen/drivers/char/console.c | 176 +
On 26.07.19 13:50, Andrew Cooper wrote:
On 26/07/2019 12:42, Juergen Gross wrote:
On 26.07.19 13:35, Jan Beulich wrote:
On 26.07.2019 11:46, Andrew Cooper wrote:
On 24/07/2019 12:26, Juergen Gross wrote:
@@ -182,30 +178,24 @@ static void __prepare_to_wait(struct
waitqueue_vcpu *wqv)
stati
flight 139434 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139434/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 22ec7474348fea2c4a32b0872dd3385bf3785a26
baseline version:
xen 52fc
On Sat, Jul 27, 2019 at 12:13:49AM +0200, Dario Faggioli wrote:
> Building with GCC9 (on openSUSE Tubmleweed) generates a lot of errors of
> the "taking address of packed member of ... may result in an unaligned
> pointer value" kind.
>
> Updating to upstream commit 1dd56dbd11082 ("[build] Workaro
flight 139408 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
flight 139412 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139412/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139342
test-amd64-i386-xl-qemuu-win7-amd64
flight 139441 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139380
Tests which
flight 139416 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 139177
Tests which di
flight 139423 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139423/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 139393
test-armhf-armhf-libvirt-raw 13 saveresto
On Fri, Feb 15, 2019 at 08:18:31AM +0530, Souptick Joarder wrote:
> Convert to use vm_map_pages() to map range of kernel
> memory to user vma.
>
> map->count is passed to vm_map_pages() and internal API
> verify map->count against count ( count = vma_pages(vma))
> for page array boundary overrun c
flight 139445 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139445/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139380
Tests which
flight 139424 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139424/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
129313
build-armhf-
flight 139452 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139380
Tests which
flight 139429 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail in
139401 REGR. vs. 139
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid xen-boot/src_host
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: lin
flight 139461 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139380
Tests which
On Tue, 23 Jul 2019 at 03:43, YOUNG, MICHAEL A. wrote:
> > Yes - this looks like a Py 2/3 compatibility issue. This particular one
> > is related to
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ff915c8cacc264ae1380d51fea07267b8308d7ba
> >
> > However, I can't explain why python i
> On Jul 22, 2019, at 15:20, Andrew Cooper wrote:
>
> a.k.a. (at least in this form) Andrew's "work which might be offloadable to
> someone else" list.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Stefano Stabellini
> CC: Tim Deegan
>
ACKed by: Shane Wang
-Original Message-
From: Roger Pau Monne [mailto:roger@citrix.com]
Sent: Thursday, July 25, 2019 9:51 PM
To: xen-devel@lists.xenproject.org
Cc: Roger Pau Monne ; Andrew Cooper
; George Dunlap ; Ian
Jackson ; Jan Beulich ; Julien
Grall ; Konrad Rzeszutek Wilk ;
Continuing on the stack saved by __prepare_to_wait() on the wrong cpu
is rather dangerous.
Instead of doing so just call the scheduler again as it already is
happening in the similar case in __prepare_to_wait() when doing the
setjmp() would be wrong.
Signed-off-by: Juergen Gross
---
xen/common/
flight 139437 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken
test-amd64-i386-xl-qemuu-win10-i386
flight 139470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/139470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 139380
Tests which
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree
26 matches
Mail list logo
