* [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
@ 2014-06-10 18:18 xen.org
0 siblings, 0 replies; 9+ messages in thread
From: xen.org @ 2014-06-10 18:18 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-saverestore
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/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Bug introduced: 2addb502cdb50bab00514b9723bf6e09c88ff75e
Bug not present: 65fc9b78ba3d868a26952db0d8e51cecf01d47b4
commit 2addb502cdb50bab00514b9723bf6e09c88ff75e
Merge: 1e1a328 65fc9b7
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue Jun 3 17:52:59 2014 +0000
Merge remote-tracking branch 'xen-staging/master' into xen-for-4.5-temp
[ a gazillion commits elided -iwj ]
Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-freebsd10-amd64.guest-saverestore.{dot,ps,png,html}.
----------------------------------------
27057: tolerable ALL FAIL
flight 27057 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/27057/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 10 guest-saverestore fail baseline untested
jobs:
test-amd64-i386-freebsd10-amd64 fail
------------------------------------------------------------
sg-report-flight on osstest.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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
@ 2015-01-17 3:51 xen.org
2015-01-19 9:27 ` Ian Campbell
0 siblings, 1 reply; 9+ messages in thread
From: xen.org @ 2015-01-17 3:51 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-freebsd10-amd64
test guest-start
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/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
Bug not present: 877eda3223161b995feacce8d2356ced1f627fa8
commit 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Jan 12 15:39:09 2015 +0100
x86/HVM: make hvm_efer_valid() honor guest features
Following the earlier similar change validating CR4 modifications.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-freebsd10-amd64.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Searching for failure / basis pass:
33418 fail [host=itch-mite] / 33368 [host=scape-moth] 33112 [host=bush-cricket] 33083 [host=grain-weevil] 33038 [host=field-cricket] 32945 [host=moss-bug] 32902 [host=gall-mite] 32877 [host=scape-moth] 32669 [host=grain-weevil] 32612 [host=lace-bug] 32594 [host=scape-moth] 32574 [host=bush-cricket] 32554 [host=field-cricket] 32535 ok.
Failure / basis pass flights: 33418 / 32535
(tree with no url: seabios)
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/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 eed8d774ce19dcae26e1cc077088397681ad65eb
Basis pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#83a926f7a4e39fb6be0576024e67fe161593defa-c3b70f0bbb6a883f4afa639286043d3f71fbbddf git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/staging/qemu-xen-unstable.git#b0d42741f8e9a00854c3b3faca1da84bfc69bf22-b0d42741f8e9a00854c3b3faca1da84bfc69bf22 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#1ebb75b1fee779621b63e84fefa7b07354c43a99-1ebb75b1fee779621b63e84fefa7b07354c43a99 git://xenbits.xen.org/xen.git#36174af3fbeb1b662c0eadbfa193e77f68cc955b-eed8d774ce19dcae26e1cc077088397681ad65eb
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/linux-pvops
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/linux-pvops.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 2001 nodes in revision graph
Searching for test results:
32503 [host=moss-bug]
32554 [host=field-cricket]
32535 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
32574 [host=bush-cricket]
32594 [host=scape-moth]
32612 [host=lace-bug]
32669 [host=grain-weevil]
32877 [host=scape-moth]
32902 [host=gall-mite]
32945 [host=moss-bug]
33038 [host=field-cricket]
33083 [host=grain-weevil]
33112 [host=bush-cricket]
33368 [host=scape-moth]
33444 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 b350fec7d3c85e4daa0ca057810e0faec2aef523
33451 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 eed8d774ce19dcae26e1cc077088397681ad65eb
33399 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 762c08496e9732822f172801d5576cd24fff784a
33440 pass e990e54996c037f654f5016c78bc03efd6e65e8b c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 ad40b1fbe41b2fc3a0dfddbbe07a9678c8cd1921
33419 pass 83a926f7a4e39fb6be0576024e67fe161593defa c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 36174af3fbeb1b662c0eadbfa193e77f68cc955b
33438 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 762c08496e9732822f172801d5576cd24fff784a
33441 pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 c9a206331067ace6416692c64c44375d51e25180
33448 pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 877eda3223161b995feacce8d2356ced1f627fa8
33446 pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 9f5584f5b6e67627d6d721ed7003469263fdeaa9
33418 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 eed8d774ce19dcae26e1cc077088397681ad65eb
33449 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 cacdb0faaa121ac8f792d5bd34cc6bc7c72d21da
33467 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
33469 pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 877eda3223161b995feacce8d2356ced1f627fa8
33470 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
33471 pass c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 877eda3223161b995feacce8d2356ced1f627fa8
33472 fail c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
Searching for interesting versions
Result found: flight 32535 (pass), for basis pass
Result found: flight 33418 (fail), for basis failure
Repro found: flight 33419 (pass), for basis pass
Repro found: flight 33451 (fail), for basis failure
0 revisions at c3b70f0bbb6a883f4afa639286043d3f71fbbddf c530a75c1e6a472b0eb9558310b518f0dfcd8860 b0d42741f8e9a00854c3b3faca1da84bfc69bf22 1ebb75b1fee779621b63e84fefa7b07354c43a99 877eda3223161b995feacce8d2356ced1f627fa8
No revisions left to test, checking graph state.
Result found: flight 33448 (pass), for last pass
Result found: flight 33467 (fail), for first failure
Repro found: flight 33469 (pass), for last pass
Repro found: flight 33470 (fail), for first failure
Repro found: flight 33471 (pass), for last pass
Repro found: flight 33472 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
Bug not present: 877eda3223161b995feacce8d2356ced1f627fa8
+ exec
+ sh -xe
+ cd /export/home/osstest/repos/xen
+ git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
commit 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Jan 12 15:39:09 2015 +0100
x86/HVM: make hvm_efer_valid() honor guest features
Following the earlier similar change validating CR4 modifications.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-freebsd10-amd64.guest-start.{dot,ps,png,html}.
----------------------------------------
33472: tolerable ALL FAIL
flight 33472 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33472/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 8 guest-start fail baseline untested
jobs:
test-amd64-i386-freebsd10-amd64 fail
------------------------------------------------------------
sg-report-flight on osstest.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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
2015-01-17 3:51 [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64 xen.org
@ 2015-01-19 9:27 ` Ian Campbell
0 siblings, 0 replies; 9+ messages in thread
From: Ian Campbell @ 2015-01-19 9:27 UTC (permalink / raw)
To: xen.org, Jan Beulich; +Cc: xen-devel, keir, stefano.stabellini
On Sat, 2015-01-17 at 03:51 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-freebsd10-amd64
> test guest-start
>
> 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/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
> Bug not present: 877eda3223161b995feacce8d2356ced1f627fa8
>
>
> commit 07a6aa869bae0699d2f7e1b75d188229eb70c9e4
> Author: Jan Beulich <jbeulich@suse.com>
> Date: Mon Jan 12 15:39:09 2015 +0100
>
> x86/HVM: make hvm_efer_valid() honor guest features
This has since been reverted, so nothing to worry about.
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
@ 2017-02-28 9:08 osstest service owner
2017-02-28 9:20 ` Roger Pau Monné
0 siblings, 1 reply; 9+ messages in thread
From: osstest service owner @ 2017-02-28 9:08 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
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/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: c5b9805bc1f793177779ae342c65fcc201a15a47
Bug not present: b199c44afa3a0d18d0e968e78a590eb9e69e20ad
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106232/
commit c5b9805bc1f793177779ae342c65fcc201a15a47
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date: Wed Feb 22 14:38:06 2017 +0100
efi: create new early memory allocator
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:
1) We could use native EFI allocation functions (e.g. AllocatePool()
or AllocatePages()) to get memory chunk. However, later (somewhere
in __start_xen()) we must copy its contents to safe place or reserve
it in e820 memory map and map it in Xen virtual address space. This
means that the code referring to Xen command line, loaded modules and
EFI memory map, mostly in __start_xen(), will be further complicated
and diverge from legacy BIOS cases. Additionally, both former things
have to be placed below 4 GiB because their addresses are stored in
multiboot_info_t structure which has 32-bit relevant members.
2) We may allocate memory area statically somewhere in Xen code which
could be used as memory pool for early dynamic allocations. Looks
quite simple. Additionally, it would not depend on EFI at all and
could be used on legacy BIOS platforms if we need it. However, we
must carefully choose size of this pool. We do not want increase Xen
binary size too much and waste too much memory but also we must fit
at least memory map on x86 EFI platforms. As I saw on small machine,
e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
So, it means that we need more than 8 KiB for EFI memory map only.
Additionally, if we use this memory pool for Xen and modules command
line storage (it would be used when xen.efi is executed as EFI application)
then we should add, I think, about 1 KiB. In this case, to be on safe
side, we should assume at least 64 KiB pool for early memory allocations.
Which is about 4 times of our earlier calculations. However, during
discussion on Xen-devel Jan Beulich suggested that just in case we should
use 1 MiB memory pool like it is in original place_string() implementation.
So, let's use 1 MiB as it was proposed. If we think that we should not
waste unallocated memory in the pool on running system then we can mark
this region as __initdata and move all required data to dynamically
allocated places somewhere in __start_xen().
2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or .init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.
Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().
New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Tested-by: Doug Goldstein <cardoe@cardoe.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot --summary-out=tmp/106232.bisection-summary --basis-template=105933 --blessings=real,real-bisect xen-unstable test-amd64-i386-freebsd10-amd64 xen-boot
Searching for failure / basis pass:
106186 fail [host=chardonnay0] / 105994 [host=nocera1] 105966 [host=nocera0] 105946 [host=elbling1] 105933 [host=fiano0] 105919 [host=elbling0] 105900 [host=pinot0] 105896 [host=fiano1] 105873 [host=nobling1] 105861 [host=merlot0] 105840 [host=italia0] 105821 [host=baroque0] 105804 [host=rimava0] 105784 [host=chardonnay1] 105766 [host=baroque1] 105756 [host=rimava1] 105742 [host=nobling0] 105728 [host=huxelrebe0] 105707 ok.
Failure / basis pass flights: 106186 / 105707
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
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/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#b669e922b37b8957248798a5eb7aa96a666cd3fe-8b4834ee1202852ed83a9fc61268c65fb6961ea7 git://xenbits.xen.org/qemu-xen.git#5cd2e1739763915e6b4c247eef71f948dc808bd5-57e8fbb2f702001a18bd81e9fe31b26d94247ac9 git://xenbits.xen.org/xen.git#6f6d3b10ec8168e2a78cf385d89803397f116397-1f24be6c945c8f8e25547aed4a56c092133df713
Loaded 7004 nodes in revision graph
Searching for test results:
105707 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
105728 [host=huxelrebe0]
105790 []
105756 [host=rimava1]
105742 [host=nobling0]
105784 [host=chardonnay1]
105766 [host=baroque1]
105804 [host=rimava0]
105821 [host=baroque0]
105840 [host=italia0]
105896 [host=fiano1]
105919 [host=elbling0]
105861 [host=merlot0]
105873 [host=nobling1]
105900 [host=pinot0]
105933 [host=fiano0]
105946 [host=elbling1]
105966 [host=nocera0]
105994 [host=nocera1]
106102 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106081 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 cf5e1a74b9687be3d146e59ab10c26be6da9d0d4
106122 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106138 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106160 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106207 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b908131167a67a16fbe9c7a7826b67e2d93d9ec5
106210 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b108240265deea37601f1a605910069a837da841
106228 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106230 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
106212 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 2c31b07ec74a29a81fdc278256c3517ae724f5e9
106231 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106200 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
106203 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106215 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 aea7cd8c0b8232a92402866774a7ee2503cbad30
106204 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 728e90b41d46c1c1c210ac496204efd51936db75 378384399ed661bed711221a5d8dbdac66b8e851
106186 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106221 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
106223 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106232 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
106225 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
Searching for interesting versions
Result found: flight 105707 (pass), for basis pass
Result found: flight 106102 (fail), for basis failure
Repro found: flight 106200 (pass), for basis pass
Repro found: flight 106203 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
No revisions left to test, checking graph state.
Result found: flight 106223 (pass), for last pass
Result found: flight 106225 (fail), for first failure
Repro found: flight 106228 (pass), for last pass
Repro found: flight 106230 (fail), for first failure
Repro found: flight 106231 (pass), for last pass
Repro found: flight 106232 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: c5b9805bc1f793177779ae342c65fcc201a15a47
Bug not present: b199c44afa3a0d18d0e968e78a590eb9e69e20ad
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106232/
commit c5b9805bc1f793177779ae342c65fcc201a15a47
Author: Daniel Kiper <daniel.kiper@oracle.com>
Date: Wed Feb 22 14:38:06 2017 +0100
efi: create new early memory allocator
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:
1) We could use native EFI allocation functions (e.g. AllocatePool()
or AllocatePages()) to get memory chunk. However, later (somewhere
in __start_xen()) we must copy its contents to safe place or reserve
it in e820 memory map and map it in Xen virtual address space. This
means that the code referring to Xen command line, loaded modules and
EFI memory map, mostly in __start_xen(), will be further complicated
and diverge from legacy BIOS cases. Additionally, both former things
have to be placed below 4 GiB because their addresses are stored in
multiboot_info_t structure which has 32-bit relevant members.
2) We may allocate memory area statically somewhere in Xen code which
could be used as memory pool for early dynamic allocations. Looks
quite simple. Additionally, it would not depend on EFI at all and
could be used on legacy BIOS platforms if we need it. However, we
must carefully choose size of this pool. We do not want increase Xen
binary size too much and waste too much memory but also we must fit
at least memory map on x86 EFI platforms. As I saw on small machine,
e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
So, it means that we need more than 8 KiB for EFI memory map only.
Additionally, if we use this memory pool for Xen and modules command
line storage (it would be used when xen.efi is executed as EFI application)
then we should add, I think, about 1 KiB. In this case, to be on safe
side, we should assume at least 64 KiB pool for early memory allocations.
Which is about 4 times of our earlier calculations. However, during
discussion on Xen-devel Jan Beulich suggested that just in case we should
use 1 MiB memory pool like it is in original place_string() implementation.
So, let's use 1 MiB as it was proposed. If we think that we should not
waste unallocated memory in the pool on running system then we can mark
this region as __initdata and move all required data to dynamically
allocated places somewhere in __start_xen().
2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or .init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.
Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().
New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
Tested-by: Doug Goldstein <cardoe@cardoe.com>
pnmtopng: 253 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
106232: tolerable ALL FAIL
flight 106232 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/106232/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 6 xen-boot fail baseline untested
jobs:
test-amd64-i386-freebsd10-amd64 fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
2017-02-28 9:08 osstest service owner
@ 2017-02-28 9:20 ` Roger Pau Monné
2017-02-28 11:37 ` Jan Beulich
2017-02-28 18:25 ` Daniel Kiper
0 siblings, 2 replies; 9+ messages in thread
From: Roger Pau Monné @ 2017-02-28 9:20 UTC (permalink / raw)
To: Daniel Kiper; +Cc: xen-devel
Hello,
It seems that your changes are causing issues when booting a 32bit Dom0, it
seems there are several IOMMU faults that prevent Dom0 from booting at all.
AFAICT this only happens when using a 32bit Dom0. The bisector has pointed
several times at this change, so it looks like the culprit.
See for example:
http://logs.test-lab.xenproject.org/osstest/logs/106186/
This is the serial log of the box failing to boot:
http://logs.test-lab.xenproject.org/osstest/logs/106186/test-amd64-i386-migrupgrade/serial-chardonnay0.log.0
Search for "[VT-D]DMAR:[DMA Read] Request device [0000:01:00.0] fault addr
7cd3f000, iommu reg = ffff82c00021b000" to get to the first IOMMU fault.
Roger.
On Tue, Feb 28, 2017 at 09:08:40AM +0000, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-freebsd10-amd64
> 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/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: c5b9805bc1f793177779ae342c65fcc201a15a47
> Bug not present: b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106232/
>
>
> commit c5b9805bc1f793177779ae342c65fcc201a15a47
> Author: Daniel Kiper <daniel.kiper@oracle.com>
> Date: Wed Feb 22 14:38:06 2017 +0100
>
> efi: create new early memory allocator
>
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and goes
> down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because then the start lives on 1 MiB address and we should
> not allocate a memory from below of it. So, I tried to use mem_lower
> address calculated by GRUB2. However, this solution works only on some
> machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> which uses first ~640 KiB for boot services code or data... :-(((
> Hence, we need new memory allocator for Xen EFI boot code which is
> quite simple and generic and could be used by place_string() and
> efi_arch_allocate_mmap_buffer(). I think about following solutions:
>
> 1) We could use native EFI allocation functions (e.g. AllocatePool()
> or AllocatePages()) to get memory chunk. However, later (somewhere
> in __start_xen()) we must copy its contents to safe place or reserve
> it in e820 memory map and map it in Xen virtual address space. This
> means that the code referring to Xen command line, loaded modules and
> EFI memory map, mostly in __start_xen(), will be further complicated
> and diverge from legacy BIOS cases. Additionally, both former things
> have to be placed below 4 GiB because their addresses are stored in
> multiboot_info_t structure which has 32-bit relevant members.
>
> 2) We may allocate memory area statically somewhere in Xen code which
> could be used as memory pool for early dynamic allocations. Looks
> quite simple. Additionally, it would not depend on EFI at all and
> could be used on legacy BIOS platforms if we need it. However, we
> must carefully choose size of this pool. We do not want increase Xen
> binary size too much and waste too much memory but also we must fit
> at least memory map on x86 EFI platforms. As I saw on small machine,
> e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
> than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
> So, it means that we need more than 8 KiB for EFI memory map only.
> Additionally, if we use this memory pool for Xen and modules command
> line storage (it would be used when xen.efi is executed as EFI application)
> then we should add, I think, about 1 KiB. In this case, to be on safe
> side, we should assume at least 64 KiB pool for early memory allocations.
> Which is about 4 times of our earlier calculations. However, during
> discussion on Xen-devel Jan Beulich suggested that just in case we should
> use 1 MiB memory pool like it is in original place_string() implementation.
> So, let's use 1 MiB as it was proposed. If we think that we should not
> waste unallocated memory in the pool on running system then we can mark
> this region as __initdata and move all required data to dynamically
> allocated places somewhere in __start_xen().
>
> 2a) We could put memory pool into .bss.page_aligned section. Then allocate
> memory chunks starting from the lowest address. After init phase we can
> free unused portion of the memory pool as in case of .init.text or .init.data
> sections. This way we do not need to allocate any space in image file and
> freeing of unused area in the memory pool is very simple.
>
> Now #2a solution is implemented because it is quite simple and requires
> limited number of changes, especially in __start_xen().
>
> New allocator is quite generic and can be used on ARM platforms too.
> Though it is not enabled on ARM yet due to lack of some prereq.
> List of them is placed before ebmalloc code.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Julien Grall <julien.grall@arm.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>
>
> For bisection revision-tuple graph see:
> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
>
> ----------------------------------------
> Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot --summary-out=tmp/106232.bisection-summary --basis-template=105933 --blessings=real,real-bisect xen-unstable test-amd64-i386-freebsd10-amd64 xen-boot
> Searching for failure / basis pass:
> 106186 fail [host=chardonnay0] / 105994 [host=nocera1] 105966 [host=nocera0] 105946 [host=elbling1] 105933 [host=fiano0] 105919 [host=elbling0] 105900 [host=pinot0] 105896 [host=fiano1] 105873 [host=nobling1] 105861 [host=merlot0] 105840 [host=italia0] 105821 [host=baroque0] 105804 [host=rimava0] 105784 [host=chardonnay1] 105766 [host=baroque1] 105756 [host=rimava1] 105742 [host=nobling0] 105728 [host=huxelrebe0] 105707 ok.
> Failure / basis pass flights: 106186 / 105707
> (tree with no url: minios)
> (tree with no url: ovmf)
> (tree with no url: seabios)
> 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/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
> Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#b669e922b37b8957248798a5eb7aa96a666cd3fe-8b4834ee1202852ed83a9fc61268c65fb6961ea7 git://xenbits.xen.org/qemu-xen.git#5cd2e1739763915e6b4c247eef71f948dc808bd5-57e8fbb2f702001a18bd81e9fe31b26d94247ac9 git://xenbits.xen.org/xen.git#6f6d3b10ec8168e2a78cf385d89803397f116397-1f24be6c945c8f8e25547aed4a56c092133df713
> Loaded 7004 nodes in revision graph
> Searching for test results:
> 105707 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
> 105728 [host=huxelrebe0]
> 105790 []
> 105756 [host=rimava1]
> 105742 [host=nobling0]
> 105784 [host=chardonnay1]
> 105766 [host=baroque1]
> 105804 [host=rimava0]
> 105821 [host=baroque0]
> 105840 [host=italia0]
> 105896 [host=fiano1]
> 105919 [host=elbling0]
> 105861 [host=merlot0]
> 105873 [host=nobling1]
> 105900 [host=pinot0]
> 105933 [host=fiano0]
> 105946 [host=elbling1]
> 105966 [host=nocera0]
> 105994 [host=nocera1]
> 106102 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106081 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 cf5e1a74b9687be3d146e59ab10c26be6da9d0d4
> 106122 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106138 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106160 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106207 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b908131167a67a16fbe9c7a7826b67e2d93d9ec5
> 106210 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b108240265deea37601f1a605910069a837da841
> 106228 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> 106230 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
> 106212 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 2c31b07ec74a29a81fdc278256c3517ae724f5e9
> 106231 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> 106200 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 5cd2e1739763915e6b4c247eef71f948dc808bd5 6f6d3b10ec8168e2a78cf385d89803397f116397
> 106203 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106215 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 aea7cd8c0b8232a92402866774a7ee2503cbad30
> 106204 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 728e90b41d46c1c1c210ac496204efd51936db75 378384399ed661bed711221a5d8dbdac66b8e851
> 106186 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
> 106221 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
> 106223 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> 106232 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
> 106225 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
> Searching for interesting versions
> Result found: flight 105707 (pass), for basis pass
> Result found: flight 106102 (fail), for basis failure
> Repro found: flight 106200 (pass), for basis pass
> Repro found: flight 106203 (fail), for basis failure
> 0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> No revisions left to test, checking graph state.
> Result found: flight 106223 (pass), for last pass
> Result found: flight 106225 (fail), for first failure
> Repro found: flight 106228 (pass), for last pass
> Repro found: flight 106230 (fail), for first failure
> Repro found: flight 106231 (pass), for last pass
> Repro found: flight 106232 (fail), for first failure
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen git://xenbits.xen.org/xen.git
> Bug introduced: c5b9805bc1f793177779ae342c65fcc201a15a47
> Bug not present: b199c44afa3a0d18d0e968e78a590eb9e69e20ad
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/106232/
>
>
> commit c5b9805bc1f793177779ae342c65fcc201a15a47
> Author: Daniel Kiper <daniel.kiper@oracle.com>
> Date: Wed Feb 22 14:38:06 2017 +0100
>
> efi: create new early memory allocator
>
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and goes
> down. Sadly this does not work when Xen is loaded using multiboot2
> protocol because then the start lives on 1 MiB address and we should
> not allocate a memory from below of it. So, I tried to use mem_lower
> address calculated by GRUB2. However, this solution works only on some
> machines. There are machines in the wild (e.g. Dell PowerEdge R820)
> which uses first ~640 KiB for boot services code or data... :-(((
> Hence, we need new memory allocator for Xen EFI boot code which is
> quite simple and generic and could be used by place_string() and
> efi_arch_allocate_mmap_buffer(). I think about following solutions:
>
> 1) We could use native EFI allocation functions (e.g. AllocatePool()
> or AllocatePages()) to get memory chunk. However, later (somewhere
> in __start_xen()) we must copy its contents to safe place or reserve
> it in e820 memory map and map it in Xen virtual address space. This
> means that the code referring to Xen command line, loaded modules and
> EFI memory map, mostly in __start_xen(), will be further complicated
> and diverge from legacy BIOS cases. Additionally, both former things
> have to be placed below 4 GiB because their addresses are stored in
> multiboot_info_t structure which has 32-bit relevant members.
>
> 2) We may allocate memory area statically somewhere in Xen code which
> could be used as memory pool for early dynamic allocations. Looks
> quite simple. Additionally, it would not depend on EFI at all and
> could be used on legacy BIOS platforms if we need it. However, we
> must carefully choose size of this pool. We do not want increase Xen
> binary size too much and waste too much memory but also we must fit
> at least memory map on x86 EFI platforms. As I saw on small machine,
> e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
> than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
> So, it means that we need more than 8 KiB for EFI memory map only.
> Additionally, if we use this memory pool for Xen and modules command
> line storage (it would be used when xen.efi is executed as EFI application)
> then we should add, I think, about 1 KiB. In this case, to be on safe
> side, we should assume at least 64 KiB pool for early memory allocations.
> Which is about 4 times of our earlier calculations. However, during
> discussion on Xen-devel Jan Beulich suggested that just in case we should
> use 1 MiB memory pool like it is in original place_string() implementation.
> So, let's use 1 MiB as it was proposed. If we think that we should not
> waste unallocated memory in the pool on running system then we can mark
> this region as __initdata and move all required data to dynamically
> allocated places somewhere in __start_xen().
>
> 2a) We could put memory pool into .bss.page_aligned section. Then allocate
> memory chunks starting from the lowest address. After init phase we can
> free unused portion of the memory pool as in case of .init.text or .init.data
> sections. This way we do not need to allocate any space in image file and
> freeing of unused area in the memory pool is very simple.
>
> Now #2a solution is implemented because it is quite simple and requires
> limited number of changes, especially in __start_xen().
>
> New allocator is quite generic and can be used on ARM platforms too.
> Though it is not enabled on ARM yet due to lack of some prereq.
> List of them is placed before ebmalloc code.
>
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> Acked-by: Jan Beulich <jbeulich@suse.com>
> Acked-by: Julien Grall <julien.grall@arm.com>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> Tested-by: Doug Goldstein <cardoe@cardoe.com>
>
> pnmtopng: 253 colors found
> Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.xen-boot.{dot,ps,png,html,svg}.
> ----------------------------------------
> 106232: tolerable ALL FAIL
>
> flight 106232 xen-unstable real-bisect [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106232/
>
> Failures :-/ but no regressions.
>
> Tests which did not succeed,
> including tests which could not be run:
> test-amd64-i386-freebsd10-amd64 6 xen-boot fail baseline untested
>
>
> jobs:
> test-amd64-i386-freebsd10-amd64 fail
>
>
> ------------------------------------------------------------
> sg-report-flight on osstest.test-lab.xenproject.org
> logs: /home/logs/logs
> images: /home/logs/images
>
> Logs, config files, etc. are available at
> http://logs.test-lab.xenproject.org/osstest/logs
>
> Explanation of these reports, and of osstest in general, is at
> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
> http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
>
> Test harness code can be found at
> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
2017-02-28 9:20 ` Roger Pau Monné
@ 2017-02-28 11:37 ` Jan Beulich
2017-02-28 11:53 ` Andrew Cooper
2017-02-28 18:25 ` Daniel Kiper
1 sibling, 1 reply; 9+ messages in thread
From: Jan Beulich @ 2017-02-28 11:37 UTC (permalink / raw)
To: Andrew Cooper, Roger Pau Monné, Daniel Kiper; +Cc: xen-devel
>>> On 28.02.17 at 10:20, <roger.pau@citrix.com> wrote:
> It seems that your changes are causing issues when booting a 32bit Dom0, it
> seems there are several IOMMU faults that prevent Dom0 from booting at all.
> AFAICT this only happens when using a 32bit Dom0. The bisector has pointed
> several times at this change, so it looks like the culprit.
>
> See for example:
>
> http://logs.test-lab.xenproject.org/osstest/logs/106186/
>
> This is the serial log of the box failing to boot:
>
> http://logs.test-lab.xenproject.org/osstest/logs/106186/test-amd64-i386-migr
> upgrade/serial-chardonnay0.log.0
>
> Search for "[VT-D]DMAR:[DMA Read] Request device [0000:01:00.0] fault addr
> 7cd3f000, iommu reg = ffff82c00021b000" to get to the first IOMMU fault.
And I think this is due to xen_in_range() (used by
vtd_set_hwdom_mapping()) not having got adjusted to cover the
freed part of .bss. Oddly enough the AMD equivalent _still_ does
not use it, but instead blindly maps everything.
Along those lines I would then also expect tboot to be broken, due
to its treatment of the [__bss_start,__bss_end) range.
Andrew, it looks like your b4cd59fea0 ("x86: reorder .data and
.init when linking") did also introduce breakage here, as
[_stext,__init_begin) no longer covers .data.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
2017-02-28 11:37 ` Jan Beulich
@ 2017-02-28 11:53 ` Andrew Cooper
0 siblings, 0 replies; 9+ messages in thread
From: Andrew Cooper @ 2017-02-28 11:53 UTC (permalink / raw)
To: Jan Beulich, Roger Pau Monné, Daniel Kiper; +Cc: xen-devel
On 28/02/17 11:37, Jan Beulich wrote:
>>>> On 28.02.17 at 10:20, <roger.pau@citrix.com> wrote:
>> It seems that your changes are causing issues when booting a 32bit Dom0, it
>> seems there are several IOMMU faults that prevent Dom0 from booting at all.
>> AFAICT this only happens when using a 32bit Dom0. The bisector has pointed
>> several times at this change, so it looks like the culprit.
>>
>> See for example:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/106186/
>>
>> This is the serial log of the box failing to boot:
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/106186/test-amd64-i386-migr
>> upgrade/serial-chardonnay0.log.0
>>
>> Search for "[VT-D]DMAR:[DMA Read] Request device [0000:01:00.0] fault addr
>> 7cd3f000, iommu reg = ffff82c00021b000" to get to the first IOMMU fault.
> And I think this is due to xen_in_range() (used by
> vtd_set_hwdom_mapping()) not having got adjusted to cover the
> freed part of .bss. Oddly enough the AMD equivalent _still_ does
> not use it, but instead blindly maps everything.
>
> Along those lines I would then also expect tboot to be broken, due
> to its treatment of the [__bss_start,__bss_end) range.
>
> Andrew, it looks like your b4cd59fea0 ("x86: reorder .data and
> .init when linking") did also introduce breakage here, as
> [_stext,__init_begin) no longer covers .data.
Hmm. So it seems. Let me put together a patch.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
2017-02-28 9:20 ` Roger Pau Monné
2017-02-28 11:37 ` Jan Beulich
@ 2017-02-28 18:25 ` Daniel Kiper
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Kiper @ 2017-02-28 18:25 UTC (permalink / raw)
To: Roger Pau Monné; +Cc: xen-devel
Hi Roger,
On Tue, Feb 28, 2017 at 09:20:05AM +0000, Roger Pau Monné wrote:
> Hello,
>
> It seems that your changes are causing issues when booting a 32bit Dom0, it
> seems there are several IOMMU faults that prevent Dom0 from booting at all.
> AFAICT this only happens when using a 32bit Dom0. The bisector has pointed
> several times at this change, so it looks like the culprit.
>
> See for example:
>
> http://logs.test-lab.xenproject.org/osstest/logs/106186/
>
> This is the serial log of the box failing to boot:
>
> http://logs.test-lab.xenproject.org/osstest/logs/106186/test-amd64-i386-migrupgrade/serial-chardonnay0.log.0
>
> Search for "[VT-D]DMAR:[DMA Read] Request device [0000:01:00.0] fault addr
> 7cd3f000, iommu reg = ffff82c00021b000" to get to the first IOMMU fault.
I have missed it. Thanks for pointing out this. We are discussing how
to solve this issue in this thread:
https://lists.xen.org/archives/html/xen-devel/2017-02/msg03537.html
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64
@ 2020-09-07 18:14 osstest service owner
0 siblings, 0 replies; 9+ messages in thread
From: osstest service owner @ 2020-09-07 18:14 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 12135 bytes --]
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-saverestore
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/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 696c273f3d9a169911308fb7e0a702a3eb6a150d
Bug not present: a609b6577f7867db4be1470130b7b3c686398c4f
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/153893/
commit 696c273f3d9a169911308fb7e0a702a3eb6a150d
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 4 11:13:01 2020 +0200
x86: generalize padding field handling
The original intention was to ignore padding fields, but the pattern
matched only ones whose names started with an underscore. Also match
fields whose names are in line with the C spec by not having a leading
underscore. (Note that the leading ^ in the sed regexps was pointless
and hence get dropped.)
This requires adjusting some vNUMA macros, to avoid triggering
"enumeration value ... not handled in switch" warnings, which - due to
-Werror - would cause the build to fail. (I have to admit that I find
these padding fields odd, when translation of the containing structure
is needed anyway.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.guest-saverestore --summary-out=tmp/153893.bisection-summary --basis-template=152877 --blessings=real,real-bisect xen-unstable test-amd64-i386-freebsd10-amd64 guest-saverestore
Searching for failure / basis pass:
153845 fail [host=chardonnay1] / 153653 [host=elbling1] 153602 [host=fiano0] 153591 [host=albana1] 153551 [host=albana0] 153526 [host=chardonnay0] 153494 [host=rimava1] 153468 [host=fiano1] 153437 [host=pinot0] 153400 [host=elbling0] 153363 [host=albana1] 153321 [host=pinot1] 153280 ok.
Failure / basis pass flights: 153845 / 153280
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
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/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 d400dc5729e4e132d61c2e7df57d81aaed762044
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 git://xenbits.xen.org/qemu-xen.git#ea6d3cd1ed79d824e605a70c3626bc4\
37c386260-ea6d3cd1ed79d824e605a70c3626bc437c386260 git://xenbits.xen.org/xen.git#d400dc5729e4e132d61c2e7df57d81aaed762044-f4c1a541fa351e4f613471bbf397931f9e1ddd27
Loaded 5001 nodes in revision graph
Searching for test results:
152985 []
153004 [host=chardonnay0]
153028 [host=fiano0]
153065 [host=huxelrebe0]
153109 [host=huxelrebe1]
153280 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 d400dc5729e4e132d61c2e7df57d81aaed762044
153321 [host=pinot1]
153363 [host=albana1]
153400 [host=elbling0]
153437 [host=pinot0]
153468 [host=fiano1]
153494 [host=rimava1]
153526 [host=chardonnay0]
153551 [host=albana0]
153591 [host=albana1]
153602 [host=fiano0]
153619 [host=elbling1]
153653 [host=elbling1]
153758 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 82c3d15c903aa434473dfdb570096ae5db809b94
153770 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
153788 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
153813 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
153865 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 d400dc5729e4e132d61c2e7df57d81aaed762044
153869 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
153871 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 7dcd33d562ee8a8177c843f42721d5345f796fe8
153874 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 7dcf89d9ec96254f69744ab6d91e8af13f4cda83
153876 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 a609b6577f7867db4be1470130b7b3c686398c4f
153879 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 696c273f3d9a169911308fb7e0a702a3eb6a150d
153845 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 f4c1a541fa351e4f613471bbf397931f9e1ddd27
153881 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 a609b6577f7867db4be1470130b7b3c686398c4f
153883 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 696c273f3d9a169911308fb7e0a702a3eb6a150d
153888 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 a609b6577f7867db4be1470130b7b3c686398c4f
153893 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 696c273f3d9a169911308fb7e0a702a3eb6a150d
Searching for interesting versions
Result found: flight 153280 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 a609b6577f7867db4be1470130b7b3c686398c4f, results HASH(0x56053f238b88) HASH(0x56053eccd228) HASH(0x56053ecd4450) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1e\
d79d824e605a70c3626bc437c386260 7dcd33d562ee8a8177c843f42721d5345f796fe8, results HASH(0x56053f2343f8) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 d400dc5729e4e132d61c2e7df57d81aaed762044, results HASH(0x56053f221cd0) HASH(0x56053f231dc8) Result found: flight 153758 (fail), for basis failure (at ancestor ~249)
Repro found: flight 153865 (pass), for basis pass
Repro found: flight 153869 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 a609b6577f7867db4be1470130b7b3c686398c4f
No revisions left to test, checking graph state.
Result found: flight 153876 (pass), for last pass
Result found: flight 153879 (fail), for first failure
Repro found: flight 153881 (pass), for last pass
Repro found: flight 153883 (fail), for first failure
Repro found: flight 153888 (pass), for last pass
Repro found: flight 153893 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 696c273f3d9a169911308fb7e0a702a3eb6a150d
Bug not present: a609b6577f7867db4be1470130b7b3c686398c4f
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/153893/
commit 696c273f3d9a169911308fb7e0a702a3eb6a150d
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Sep 4 11:13:01 2020 +0200
x86: generalize padding field handling
The original intention was to ignore padding fields, but the pattern
matched only ones whose names started with an underscore. Also match
fields whose names are in line with the C spec by not having a leading
underscore. (Note that the leading ^ in the sed regexps was pointless
and hence get dropped.)
This requires adjusting some vNUMA macros, to avoid triggering
"enumeration value ... not handled in switch" warnings, which - due to
-Werror - would cause the build to fail. (I have to admit that I find
these padding fields odd, when translation of the containing structure
is needed anyway.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-freebsd10-amd64.guest-saverestore.{dot,ps,png,html,svg}.
----------------------------------------
153893: tolerable ALL FAIL
flight 153893 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/153893/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail baseline untested
jobs:
test-amd64-i386-freebsd10-amd64 fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-09-07 18:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-17 3:51 [xen-unstable bisection] complete test-amd64-i386-freebsd10-amd64 xen.org
2015-01-19 9:27 ` Ian Campbell
-- strict thread matches above, loose matches on Subject: below --
2020-09-07 18:14 osstest service owner
2017-02-28 9:08 osstest service owner
2017-02-28 9:20 ` Roger Pau Monné
2017-02-28 11:37 ` Jan Beulich
2017-02-28 11:53 ` Andrew Cooper
2017-02-28 18:25 ` Daniel Kiper
2014-06-10 18:18 xen.org
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.