* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2016-10-30 4:29 osstest service owner
2016-10-30 16:53 ` Andrew Cooper
2016-10-30 17:31 ` Andrew Cooper
0 siblings, 2 replies; 17+ messages in thread
From: osstest service owner @ 2016-10-30 4:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: 0897514b4b376a167f968f79c6ea0dee1061458e
Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
commit 0897514b4b376a167f968f79c6ea0dee1061458e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Oct 26 10:34:21 2016 +0100
tools/oxenstored: Avoid allocating invalid transaction ids
The transaction id of 0 is reserved, meaning "not in a transaction". It is up
to the xenstored server to allocate transaction ids. While oxenstored starts
its ids at 1, but insufficient care is taken with truncation cases.
A 32bit oxenstored has an int with 31 bits of width, meaning that the
transaction id will wrap around to 0 after 2 billion transactions.
A 64bit oxenstored has an int with 63 bits of width, meaning that once 4
billion transactions are used, the allocated id will be truncated when written
into the uin32_t field in the ring. This causes the client to reply with the
truncated id, breaking any further attempt to use any transactions.
Limit all transaction ids to the range between 1 and 0x7ffffffe. This is the
best which can be done without making oxenstored depend on Stdint or Cstruct,
yet still work for 32bit builds.
Also check that the proposed new transaction id isn't currently in use. For
the first 2 billion transactions there is no chance of a collision, and after
that, the chance is at most 20 (the default open transaction quota) in 2
billion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Scott <dave@recoil.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/101803.bisection-summary --basis-template=101673 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
101780 fail [host=nobling0] / 101673 [host=nobling1] 101654 [host=chardonnay0] 101644 [host=fiano1] 101626 [host=nocera0] 101601 [host=elbling1] 101590 [host=italia0] 101571 [host=elbling0] 101563 [host=pinot0] 101555 [host=chardonnay1] 101546 [host=italia1] 101533 [host=baroque0] 101510 [host=huxelrebe1] 101496 [host=fiano0] 101491 [host=baroque1] 101484 [host=chardonnay0] 101475 [host=huxelrebe0] 101440 [host=fiano1] 101429 [host=elbling1] 101415 [host=italia1] 101396 [host=italia0] 101383 [host=nobling1] 101379 [host=elbling0] 101372 [host=chardonnay1] 101364 ok.
Failure / basis pass flights: 101780 / 101364
(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 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 35ac0c08178ac15565b32ca56b00fa5414f1d3b1
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 570117996772b762e9654e58e708943a4db68b4f 68dc7185cbffab34211c77339874f2ea517990fd
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#c4e0d84d3c92923fdbc7fa922638d54e5e834753-c4e0d84d3c92923fdbc7fa922638d54e5e834753 git://xenbits.xen.org/qemu-xen.git#570117996772b762e9654e58e708943a4db68b4f-6cfcdf037edadba984ccf8476b5d1e2a0940b789 git://xenbits.xen.org/xen.git#68dc7185cbffab34211c77339874f2ea517990fd-35ac0c08178ac15565b32ca56b00fa5414f1d3b1
Loaded 2004 nodes in revision graph
Searching for test results:
101364 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 570117996772b762e9654e58e708943a4db68b4f 68dc7185cbffab34211c77339874f2ea517990fd
101372 [host=chardonnay1]
101379 [host=elbling0]
101383 [host=nobling1]
101415 [host=italia1]
101396 [host=italia0]
101429 [host=elbling1]
101440 [host=fiano1]
101475 [host=huxelrebe0]
101484 [host=chardonnay0]
101491 [host=baroque1]
101546 [host=italia1]
101496 [host=fiano0]
101533 [host=baroque0]
101510 [host=huxelrebe1]
101555 [host=chardonnay1]
101590 [host=italia0]
101563 [host=pinot0]
101571 [host=elbling0]
101601 [host=elbling1]
101626 [host=nocera0]
101654 [host=chardonnay0]
101644 [host=fiano1]
101673 [host=nobling1]
101698 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 e26722422764d3ddfe59e76f5efbd330f8f9288f
101780 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 35ac0c08178ac15565b32ca56b00fa5414f1d3b1
101790 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 2f5a483928116781025d2334684e8a0c2eb8792e
101756 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 a418ec07cf2668197548c6503924139a2098e41d
101791 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 35ac0c08178ac15565b32ca56b00fa5414f1d3b1
101801 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 4000a7c7d7b0e01837abd3918e393f289c07d68c
101793 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 4000a7c7d7b0e01837abd3918e393f289c07d68c
101726 []
101803 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 0897514b4b376a167f968f79c6ea0dee1061458e
101794 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 1b843b2097e89d0fae18123cde88da9d167d9a0c
101786 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 570117996772b762e9654e58e708943a4db68b4f 68dc7185cbffab34211c77339874f2ea517990fd
101787 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 a418ec07cf2668197548c6503924139a2098e41d
101797 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 0897514b4b376a167f968f79c6ea0dee1061458e
101789 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 570117996772b762e9654e58e708943a4db68b4f 8b4664265bb398db4d5581959566a3f8036696ce
101798 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 4000a7c7d7b0e01837abd3918e393f289c07d68c
101799 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 0897514b4b376a167f968f79c6ea0dee1061458e
Searching for interesting versions
Result found: flight 101364 (pass), for basis pass
Result found: flight 101780 (fail), for basis failure
Repro found: flight 101786 (pass), for basis pass
Repro found: flight 101791 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c4e0d84d3c92923fdbc7fa922638d54e5e834753 6cfcdf037edadba984ccf8476b5d1e2a0940b789 4000a7c7d7b0e01837abd3918e393f289c07d68c
No revisions left to test, checking graph state.
Result found: flight 101793 (pass), for last pass
Result found: flight 101797 (fail), for first failure
Repro found: flight 101798 (pass), for last pass
Repro found: flight 101799 (fail), for first failure
Repro found: flight 101801 (pass), for last pass
Repro found: flight 101803 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 0897514b4b376a167f968f79c6ea0dee1061458e
Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
commit 0897514b4b376a167f968f79c6ea0dee1061458e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Oct 26 10:34:21 2016 +0100
tools/oxenstored: Avoid allocating invalid transaction ids
The transaction id of 0 is reserved, meaning "not in a transaction". It is up
to the xenstored server to allocate transaction ids. While oxenstored starts
its ids at 1, but insufficient care is taken with truncation cases.
A 32bit oxenstored has an int with 31 bits of width, meaning that the
transaction id will wrap around to 0 after 2 billion transactions.
A 64bit oxenstored has an int with 63 bits of width, meaning that once 4
billion transactions are used, the allocated id will be truncated when written
into the uin32_t field in the ring. This causes the client to reply with the
truncated id, breaking any further attempt to use any transactions.
Limit all transaction ids to the range between 1 and 0x7ffffffe. This is the
best which can be done without making oxenstored depend on Stdint or Cstruct,
yet still work for 32bit builds.
Also check that the proposed new transaction id isn't currently in use. For
the first 2 billion transactions there is no chance of a collision, and after
that, the chance is at most 20 (the default open transaction quota) in 2
billion.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: David Scott <dave@recoil.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
101803: tolerable ALL FAIL
flight 101803 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/101803/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2016-10-30 4:29 [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm osstest service owner
@ 2016-10-30 16:53 ` Andrew Cooper
2016-10-31 15:00 ` Wei Liu
2016-10-30 17:31 ` Andrew Cooper
1 sibling, 1 reply; 17+ messages in thread
From: Andrew Cooper @ 2016-10-30 16:53 UTC (permalink / raw)
To: Wei Liu, Ian Jackson, Daniel De Graaf; +Cc: Xen-devel List
On 30/10/16 04:29, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> testid debian-hvm-install
>
> 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: 0897514b4b376a167f968f79c6ea0dee1061458e
> Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
>
>
> commit 0897514b4b376a167f968f79c6ea0dee1061458e
> Author: Andrew Cooper <andrew.cooper3@citrix.com>
> Date: Wed Oct 26 10:34:21 2016 +0100
>
> tools/oxenstored: Avoid allocating invalid transaction ids
I have to admit that I am staring at this report in belief, but it is
apparently deterministic. It is very strange that only this job is
affected; if there was actually a problem with xenstore transactions, I
would have thought that there to be collateral damage everywhere.
Looking through the logs, there are several concerning things happening
even in the success cases.
First:
(XEN) HVM1 restore: CPU 0
(XEN) avc: denied { getvcpucontext } for domid=0 target=2
scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dm_dom_t
tclass=domain
The toolstack calls getvcpucontext as part of domain creation, and the
XSM policy disallows this on dm_dom_t's. Interestingly, this failure
doesn't appear to be fatal to domain creation, and it really ought to
be. I expect there is also another bug lurking in the lower levels of
the toolstack.
Second:
(XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:577
(XEN) ----[ Xen-4.8.0-rc x86_64 debug=y Not tainted ]----
<snip>
(XEN) Xen call trace:
(XEN) [<ffff82d08013cf20>] _xmalloc+0x2f/0x313
(XEN) [<ffff82d08016a6f9>] services.c#context_struct_to_string+0x98/0x16d
(XEN) [<ffff82d08016c0c2>] security_sid_to_context+0xd3/0xe7
(XEN) [<ffff82d080162596>] hooks.c#flask_show_security_evtchn+0x6f/0x87
(XEN) [<ffff82d08010819a>] event_channel.c#dump_evtchn_info+0x246/0x2cb
(XEN) [<ffff82d080116271>] handle_keypress+0x8c/0xac
(XEN) [<ffff82d08014600b>] console.c#__serial_rx+0x38/0x73
(XEN) [<ffff82d0801467ea>] console.c#serial_rx+0x8a/0x8f
(XEN) [<ffff82d080148b17>] serial_rx_interrupt+0x90/0xac
(XEN) [<ffff82d08014756a>] ns16550.c#ns16550_interrupt+0x57/0x71
(XEN) [<ffff82d0801839fb>] do_IRQ+0x56e/0x60f
(XEN) [<ffff82d080254d67>] common_interrupt+0x67/0x70
(XEN) [<ffff82d0801cd586>] mwait-idle.c#mwait_idle+0x2af/0x2f9
The 'e' debugkey isn't safe to use when XSM is compiled in, as
security_sid_to_context() allocates memory.
Furthermore, any unexpected host crashes should cause a failure of the
test. This appears to have gone unnoticed because it happens in the
capture-logs phase, with presumably sufficient timeouts that OSSTest
doesn't notice that the host rebooted in the middle of log collection.
Third:
(d2) **************************
(d2) blk_open(/local/domain/2/device/vbd/5632) -> 6
(d2) xs_watch(device-model/1/logdirty/cmd, logdirty)
(d2) xs_watch(device-model/1/command, dm-command)
(d2) xs_watch(/local/domain/1/cpu, vcpu-set)
(d2) xs_read(/local/domain/0/backend/pci/1/0/msitranslate): ENOENT
(d2) xs_read(/local/domain/0/backend/pci/1/0/power_mgmt): ENOENT
(d2) open(/var/log/dm-serial.log) -> 7
(d2) fcntl(-1, 3, 3ffbc8/17775710)
(d2) fcntl(-1, 4, ffffffff/37777777777)
(d2) fcntl(7, 3, ffffffff/37777777777)
(d2) fcntl(7, 4, ffffffff/37777777777)
(d2) xs_watch(/local/domain/0/backend/console/1, be:0x14b1a7:1:0x186800)
(d2) xs_directory(/local/domain/0/backend/console/1): EACCES
(d2) xs_watch(/local/domain/0/backend/vkbd/1, be:0x1479ff:1:0x1867c0)
(d2) xs_directory(/local/domain/0/backend/vkbd/1): EACCES
(d2) xs_read(device-model/1/disable_pf): ENOENT
(d2) xs_watch(/local/domain/1/log-throttling,
/local/domain/1/log-throttling)
(d2) Thread "kbdfront": pointer: 0x0xb0182570, stack: 0x0xaa0000
(d2) ******************* FBFRONT for /local/domain/2/device/vfb/0 **********
The stub qemu attempts to read d1's backends. It probably shouldn't be
doing that.
Comparing the xenstored-access logs, between the success and failure
cases, it does appear that in the failing case, all transactions have
the id 1. I am trying to debug why.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2016-10-30 4:29 [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm osstest service owner
2016-10-30 16:53 ` Andrew Cooper
@ 2016-10-30 17:31 ` Andrew Cooper
2016-10-31 10:31 ` Ian Jackson
1 sibling, 1 reply; 17+ messages in thread
From: Andrew Cooper @ 2016-10-30 17:31 UTC (permalink / raw)
To: Ian Jackson, Wei Liu; +Cc: David Scott, Xen-devel List
On 30/10/16 04:29, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> testid debian-hvm-install
>
> 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: 0897514b4b376a167f968f79c6ea0dee1061458e
> Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
>
>
> commit 0897514b4b376a167f968f79c6ea0dee1061458e
> Author: Andrew Cooper <andrew.cooper3@citrix.com>
> Date: Wed Oct 26 10:34:21 2016 +0100
>
> tools/oxenstored: Avoid allocating invalid transaction ids
Looking at xenstored-access.log before:
A8.1 write /vm/6fc3ae48-3d32-4710-aaac-55801d273773/uuid
6fc3ae48-3d32-4710-aaac-55801d273773
A8.1 write /vm/6fc3ae48-3d32-4710-aaac-55801d273773/name
debianhvm.guest.osstest
A8.1 write
/local/domain/1/control/platform-feature-multiprocessor-suspend 1
A8.1 write
/local/domain/1/control/platform-feature-xs_reset_watches 1
A8.1 commit
A8 write /libxl/1/dm-version qemu_xen_traditional
A8.2 write /local/domain/1/memory/static-max 5120000
A8.2 write /local/domain/1/memory/target 5115904
A8.2 write /local/domain/1/memory/videoram 4096
A8.2 write /local/domain/1/domid 1
And after:
A8.1 write /vm/0a3c1b35-33f8-432d-aab7-b98ea16d490f/uuid
0a3c1b35-33f8-432d-aab7-b98ea16d490f
A8.1 write /vm/0a3c1b35-33f8-432d-aab7-b98ea16d490f/name
debianhvm.guest.osstest
A8.1 write
/local/domain/1/control/platform-feature-multiprocessor-suspend 1
A8.1 write
/local/domain/1/control/platform-feature-xs_reset_watches 1
A8.1 commit
A8 write /libxl/1/dm-version qemu_xen_traditional
A8.1 write /local/domain/1/memory/static-max 5120000
A8.1 write /local/domain/1/memory/target 5115904
A8.1 write /local/domain/1/memory/videoram 4096
A8.1 write /local/domain/1/domid 1
the logging shows that almost all details are identical, other than the
transaction ids on successive transactions.
Compiling oxenstored locally on my dev box (and in the XenServer build
system) confirms that transaction ids behave as intended, i.e. ids are
allocated incrementally, even with the identified changeset in place.
Where can I find the build logs for the bisection runs? I am fairly
sure I have a newer version of Ocaml than comes by default in Debian,
and I wonder whether I have hit some version-dependent behaviour.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2016-10-30 17:31 ` Andrew Cooper
@ 2016-10-31 10:31 ` Ian Jackson
2016-10-31 10:37 ` Andrew Cooper
0 siblings, 1 reply; 17+ messages in thread
From: Ian Jackson @ 2016-10-31 10:31 UTC (permalink / raw)
To: Andrew Cooper; +Cc: David Scott, Wei Liu, Xen-devel List
Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm"):
> On 30/10/16 04:29, osstest service owner wrote:
> > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
...
> Where can I find the build logs for the bisection runs? I am fairly
> sure I have a newer version of Ocaml than comes by default in Debian,
> and I wonder whether I have hit some version-dependent behaviour.
Let me walk you through this.
We'll follow links starting with, say, the "Last fail repro" url,
above:
http://logs.test-lab.xenproject.org/osstest/logs/101803/
Click on the test column heading to get to
http://logs.test-lab.xenproject.org/osstest/logs/101803/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/info.html
Scroll down and you'll see `Test control variables'. Select the build
of interest, which I think is `buildjob'. (There are also
`xenbuildjob' which is the hypervisor build, and `kernbuildjob' which
is, as might be expected, the kernel.) So click through to
101797.build-i386-xsm:
http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/info.html
The main build log is that for the `xen-build' step:
http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/4.ts-xen-build-prep.log
Finding out which ocaml was actually installed can sometimes be a
little harder, because build host sharing means that the run of
`host-build-prep' shown in that job might be a no-op, and there isn't
an easy way to click through to the job that actually did the install
(sorry).
However, it's easy enough to know what ocaml was probably installed:
looking at `Test control variables' in the build job, you see
`all_host_suite' with value `jessie'. Then go here
https://www.debian.org/distrib/packages
and in the `search package directories' enter `ocaml' (searching
within `stable', since jessie is currently stable);
https://packages.debian.org/search?keywords=ocaml&searchon=names&suite=stable§ion=all
Results: 4.01.0-5.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2016-10-31 10:31 ` Ian Jackson
@ 2016-10-31 10:37 ` Andrew Cooper
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Cooper @ 2016-10-31 10:37 UTC (permalink / raw)
To: Ian Jackson; +Cc: David Scott, Wei Liu, Xen-devel List
On 31/10/16 10:31, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm"):
>> On 30/10/16 04:29, osstest service owner wrote:
>>> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
> ...
>> Where can I find the build logs for the bisection runs? I am fairly
>> sure I have a newer version of Ocaml than comes by default in Debian,
>> and I wonder whether I have hit some version-dependent behaviour.
> Let me walk you through this.
>
> We'll follow links starting with, say, the "Last fail repro" url,
> above:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101803/
>
> Click on the test column heading to get to
>
> http://logs.test-lab.xenproject.org/osstest/logs/101803/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/info.html
>
> Scroll down and you'll see `Test control variables'. Select the build
> of interest, which I think is `buildjob'. (There are also
> `xenbuildjob' which is the hypervisor build, and `kernbuildjob' which
> is, as might be expected, the kernel.) So click through to
> 101797.build-i386-xsm:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/info.html
>
> The main build log is that for the `xen-build' step:
>
> http://logs.test-lab.xenproject.org/osstest/logs/101797/build-i386-xsm/4.ts-xen-build-prep.log
>
> Finding out which ocaml was actually installed can sometimes be a
> little harder, because build host sharing means that the run of
> `host-build-prep' shown in that job might be a no-op, and there isn't
> an easy way to click through to the job that actually did the install
> (sorry).
>
> However, it's easy enough to know what ocaml was probably installed:
> looking at `Test control variables' in the build job, you see
> `all_host_suite' with value `jessie'. Then go here
>
> https://www.debian.org/distrib/packages
>
> and in the `search package directories' enter `ocaml' (searching
> within `stable', since jessie is currently stable);
>
> https://packages.debian.org/search?keywords=ocaml&searchon=names&suite=stable§ion=all
>
> Results: 4.01.0-5.
Thankyou. It turns out that I am using the same version of Ocaml.
However, looking at the build log, I think the fact that this is a 32bit
build of the binary might be the salient point. Let me see if I can
rebuild oxenstored as 32bit.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2016-10-30 16:53 ` Andrew Cooper
@ 2016-10-31 15:00 ` Wei Liu
0 siblings, 0 replies; 17+ messages in thread
From: Wei Liu @ 2016-10-31 15:00 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Ian Jackson, Daniel De Graaf, Wei Liu, Xen-devel List
On Sun, Oct 30, 2016 at 04:53:33PM +0000, Andrew Cooper wrote:
> On 30/10/16 04:29, osstest service owner wrote:
> > branch xen-unstable
> > xenbranch xen-unstable
> > job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> > testid debian-hvm-install
> >
> > 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: 0897514b4b376a167f968f79c6ea0dee1061458e
> > Bug not present: 4000a7c7d7b0e01837abd3918e393f289c07d68c
> > Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101803/
> >
> >
> > commit 0897514b4b376a167f968f79c6ea0dee1061458e
> > Author: Andrew Cooper <andrew.cooper3@citrix.com>
> > Date: Wed Oct 26 10:34:21 2016 +0100
> >
> > tools/oxenstored: Avoid allocating invalid transaction ids
>
> I have to admit that I am staring at this report in belief, but it is
> apparently deterministic. It is very strange that only this job is
> affected; if there was actually a problem with xenstore transactions, I
> would have thought that there to be collateral damage everywhere.
>
> Looking through the logs, there are several concerning things happening
> even in the success cases.
>
> First:
>
> (XEN) HVM1 restore: CPU 0
> (XEN) avc: denied { getvcpucontext } for domid=0 target=2
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dm_dom_t
> tclass=domain
>
> The toolstack calls getvcpucontext as part of domain creation, and the
> XSM policy disallows this on dm_dom_t's. Interestingly, this failure
> doesn't appear to be fatal to domain creation, and it really ought to
> be. I expect there is also another bug lurking in the lower levels of
> the toolstack.
>
No idea about this at the moment.
> Second:
>
> (XEN) Assertion '!in_irq()' failed at xmalloc_tlsf.c:577
> (XEN) ----[ Xen-4.8.0-rc x86_64 debug=y Not tainted ]----
> <snip>
> (XEN) Xen call trace:
> (XEN) [<ffff82d08013cf20>] _xmalloc+0x2f/0x313
> (XEN) [<ffff82d08016a6f9>] services.c#context_struct_to_string+0x98/0x16d
> (XEN) [<ffff82d08016c0c2>] security_sid_to_context+0xd3/0xe7
> (XEN) [<ffff82d080162596>] hooks.c#flask_show_security_evtchn+0x6f/0x87
> (XEN) [<ffff82d08010819a>] event_channel.c#dump_evtchn_info+0x246/0x2cb
> (XEN) [<ffff82d080116271>] handle_keypress+0x8c/0xac
> (XEN) [<ffff82d08014600b>] console.c#__serial_rx+0x38/0x73
> (XEN) [<ffff82d0801467ea>] console.c#serial_rx+0x8a/0x8f
> (XEN) [<ffff82d080148b17>] serial_rx_interrupt+0x90/0xac
> (XEN) [<ffff82d08014756a>] ns16550.c#ns16550_interrupt+0x57/0x71
> (XEN) [<ffff82d0801839fb>] do_IRQ+0x56e/0x60f
> (XEN) [<ffff82d080254d67>] common_interrupt+0x67/0x70
> (XEN) [<ffff82d0801cd586>] mwait-idle.c#mwait_idle+0x2af/0x2f9
>
> The 'e' debugkey isn't safe to use when XSM is compiled in, as
> security_sid_to_context() allocates memory.
>
This can not be easily fixed without reworking the XSM framework API. I
propose we just disable the offending snippet.
> Furthermore, any unexpected host crashes should cause a failure of the
> test. This appears to have gone unnoticed because it happens in the
> capture-logs phase, with presumably sufficient timeouts that OSSTest
> doesn't notice that the host rebooted in the middle of log collection.
>
> Third:
>
> (d2) **************************
> (d2) blk_open(/local/domain/2/device/vbd/5632) -> 6
> (d2) xs_watch(device-model/1/logdirty/cmd, logdirty)
> (d2) xs_watch(device-model/1/command, dm-command)
> (d2) xs_watch(/local/domain/1/cpu, vcpu-set)
> (d2) xs_read(/local/domain/0/backend/pci/1/0/msitranslate): ENOENT
> (d2) xs_read(/local/domain/0/backend/pci/1/0/power_mgmt): ENOENT
> (d2) open(/var/log/dm-serial.log) -> 7
> (d2) fcntl(-1, 3, 3ffbc8/17775710)
> (d2) fcntl(-1, 4, ffffffff/37777777777)
> (d2) fcntl(7, 3, ffffffff/37777777777)
> (d2) fcntl(7, 4, ffffffff/37777777777)
> (d2) xs_watch(/local/domain/0/backend/console/1, be:0x14b1a7:1:0x186800)
> (d2) xs_directory(/local/domain/0/backend/console/1): EACCES
> (d2) xs_watch(/local/domain/0/backend/vkbd/1, be:0x1479ff:1:0x1867c0)
> (d2) xs_directory(/local/domain/0/backend/vkbd/1): EACCES
> (d2) xs_read(device-model/1/disable_pf): ENOENT
> (d2) xs_watch(/local/domain/1/log-throttling,
> /local/domain/1/log-throttling)
> (d2) Thread "kbdfront": pointer: 0x0xb0182570, stack: 0x0xaa0000
> (d2) ******************* FBFRONT for /local/domain/2/device/vfb/0 **********
>
> The stub qemu attempts to read d1's backends. It probably shouldn't be
> doing that.
>
This is (supposedly) harmless, so a low priority bug.
Wei.
>
> Comparing the xenstored-access logs, between the success and failure
> cases, it does appear that in the failing case, all transactions have
> the id 1. I am trying to debug why.
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2023-12-10 19:11 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2023-12-10 19:11 UTC (permalink / raw)
To: xen-devel
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: bc4fe94a69d4dab103c37045d97e589ef75f8647
Bug not present: e6e8c5831a64420a56f83e87919ed157ab810fab
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184083/
commit bc4fe94a69d4dab103c37045d97e589ef75f8647
Author: Juergen Gross <jgross@suse.com>
Date: Thu Dec 7 07:25:51 2023 +0100
tools/libs/evtchn: replace assert()s in stubdom with proper locking
In tools/libs/evtchn/minios.c there are assert()s for the current
thread being the main thread when binding an event channel.
As Mini-OS is supporting multiple threads, there is no real reason
why the binding shouldn't be allowed to happen in any other thread.
Drop the assert()s and replace them with proper locking of the
port_list.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/184083.bisection-summary --basis-template=184031 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
184064 fail [host=albana0] / 184031 [host=elbling0] 184020 [host=debina0] 184005 [host=albana1] 183996 [host=huxelrebe1] 183990 [host=debina1] 183983 [host=nobling0] 183978 [host=rimava1] 183974 ok.
Failure / basis pass flights: 184064 / 183974
(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 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 525c7c094b258e8a46b494488eef96f5670eb352
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#0df9387c8983e1b1e72d8c574356f57\
2342c03e6-0df9387c8983e1b1e72d8c574356f572342c03e6 git://xenbits.xen.org/xen.git#525c7c094b258e8a46b494488eef96f5670eb352-bc4fe94a69d4dab103c37045d97e589ef75f8647
Loaded 5001 nodes in revision graph
Searching for test results:
183971 [host=fiano1]
183990 [host=debina1]
183974 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 525c7c094b258e8a46b494488eef96f5670eb352
183978 [host=rimava1]
183983 [host=nobling0]
183996 [host=huxelrebe1]
184005 [host=albana1]
184020 [host=debina0]
184031 [host=elbling0]
184036 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184044 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184053 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184066 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 525c7c094b258e8a46b494488eef96f5670eb352
184067 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184070 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 634c6e15ac44cd6b09a79126bf1424fd72ab31df
184071 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 dbe69e1c8555b40a43cde482615501eb8515ab80
184072 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 02d0a615b32d03702f79807fa5e88f0cf78dde84
184064 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184073 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 25147005daf5a4e121b96496d6d208fac05fca35
184075 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 d2b7c442b4a066bb670ee83e24800cabc415241d
184077 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e6e8c5831a64420a56f83e87919ed157ab810fab
184079 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184080 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e6e8c5831a64420a56f83e87919ed157ab810fab
184081 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
184082 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e6e8c5831a64420a56f83e87919ed157ab810fab
184083 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 bc4fe94a69d4dab103c37045d97e589ef75f8647
Searching for interesting versions
Result found: flight 183974 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e6e8c5831a64420a56f83e87919ed157ab810fab, results HASH(0x55f51ec0f3e0) HASH(0x55f51ebfffd8) HASH(0x55f51e6abe10) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8\
983e1b1e72d8c574356f572342c03e6 d2b7c442b4a066bb670ee83e24800cabc415241d, results HASH(0x55f51ec08c20) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 25147005daf5a4e121b96496d6d208fac05fca35, results HASH(0x55f51ec0e960) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\
0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 02d0a615b32d03702f79807fa5e88f0cf78dde84, results HASH(0x55f51ec09848) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 dbe69e1c8555b40a43cde482615501eb8515ab80, results HASH(0x55f51ec09548) For basis failure, parent search stopping at c3038e718a19\
fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 634c6e15ac44cd6b09a79126bf1424fd72ab31df, results HASH(0x55f51ec084a0) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 525c7c094b258e8a46b494488eef96f5670eb352, results HASH(0x55f51ebfac2\
0) HASH(0x55f51ec0ac50) Result found: flight 184036 (fail), for basis failure (at ancestor ~2514)
Repro found: flight 184066 (pass), for basis pass
Repro found: flight 184067 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 0df9387c8983e1b1e72d8c574356f572342c03e6 e6e8c5831a64420a56f83e87919ed157ab810fab
No revisions left to test, checking graph state.
Result found: flight 184077 (pass), for last pass
Result found: flight 184079 (fail), for first failure
Repro found: flight 184080 (pass), for last pass
Repro found: flight 184081 (fail), for first failure
Repro found: flight 184082 (pass), for last pass
Repro found: flight 184083 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: bc4fe94a69d4dab103c37045d97e589ef75f8647
Bug not present: e6e8c5831a64420a56f83e87919ed157ab810fab
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/184083/
commit bc4fe94a69d4dab103c37045d97e589ef75f8647
Author: Juergen Gross <jgross@suse.com>
Date: Thu Dec 7 07:25:51 2023 +0100
tools/libs/evtchn: replace assert()s in stubdom with proper locking
In tools/libs/evtchn/minios.c there are assert()s for the current
thread being the main thread when binding an event channel.
As Mini-OS is supporting multiple threads, there is no real reason
why the binding shouldn't be allowed to happen in any other thread.
Drop the assert()s and replace them with proper locking of the
port_list.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
184083: tolerable ALL FAIL
flight 184083 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/184083/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2022-11-20 8:28 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2022-11-20 8:28 UTC (permalink / raw)
To: xen-devel
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
Bug not present: bd87315a603bf25e869e6293f7db7b1024d67999
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/174855/
commit 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Oct 25 15:27:05 2022 +0100
xen/arm, libxl: Revert XEN_DOMCTL_shadow_op; use p2m mempool hypercalls
This reverts most of commit cf2a68d2ffbc3ce95e01449d46180bddb10d24a0, and bits
of cbea5a1149ca7fd4b7cdbfa3ec2e4f109b601ff7.
First of all, with ARM borrowing x86's implementation, the logic to set the
pool size should have been common, not duplicated. Introduce
libxl__domain_set_paging_mempool_size() as a shared implementation, and use it
from the ARM and x86 paths. It is left as an exercise to the reader to judge
how libxl/xl can reasonably function without the ability to query the pool
size...
Remove ARM's p2m_domctl() infrastructure now the functioanlity has been
replaced with a working and unit tested interface.
This is part of XSA-409 / CVE-2022-33747.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/174855.bisection-summary --basis-template=174797 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
174843 fail [host=debina1] / 174797 [host=chardonnay0] 174791 [host=albana1] 174773 [host=albana0] 174769 [host=nocera1] 174762 [host=huxelrebe1] 174753 [host=nobling0] 174747 [host=elbling0] 174742 [host=debina0] 174733 [host=huxelrebe0] 174724 [host=fiano1] 174701 [host=pinot0] 174682 [host=pinot1] 174670 [host=italia1] 174663 [host=nobling1] 174652 [host=chardonnay1] 174641 [host=nocera0] 174636 [host=elbling1] 174629 [host=chardonnay0] 174607 ok.
Failure / basis pass flights: 174843 / 174607
(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 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 2d9b3699136d20e354a94daefebbeefa9ceec7b6
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#b746458e1ce1bec85e58b458386f8b7\
a0bedfaa6-b746458e1ce1bec85e58b458386f8b7a0bedfaa6 git://xenbits.xen.org/xen.git#2d9b3699136d20e354a94daefebbeefa9ceec7b6-db8fa01c61db0317a9ee947925226234c65d48e8
Loaded 5001 nodes in revision graph
Searching for test results:
174607 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 2d9b3699136d20e354a94daefebbeefa9ceec7b6
174629 [host=chardonnay0]
174636 [host=elbling1]
174641 [host=nocera0]
174652 [host=chardonnay1]
174663 [host=nobling1]
174670 [host=italia1]
174682 [host=pinot1]
174701 [host=pinot0]
174724 [host=fiano1]
174733 [host=huxelrebe0]
174742 [host=debina0]
174747 [host=elbling0]
174753 [host=nobling0]
174762 [host=huxelrebe1]
174769 [host=nocera1]
174773 [host=albana0]
174791 [host=albana1]
174797 [host=chardonnay0]
174814 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
174819 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
174826 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
174842 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 2d9b3699136d20e354a94daefebbeefa9ceec7b6
174844 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
174845 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 c805ceb0b26a643c7e47f01f2dbc50555d93cce8
174846 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 c62748312e0adec0cbcf0f8d7d126080e5e43a82
174847 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 e5ac68a0110cb43a3a0bc17d545ae7a0bd746ef9
174848 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 bd87315a603bf25e869e6293f7db7b1024d67999
174849 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
174850 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 bd87315a603bf25e869e6293f7db7b1024d67999
174851 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
174843 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 db8fa01c61db0317a9ee947925226234c65d48e8
174853 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 bd87315a603bf25e869e6293f7db7b1024d67999
174855 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
Searching for interesting versions
Result found: flight 174607 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 bd87315a603bf25e869e6293f7db7b1024d67999, results HASH(0x55b3d7e96a50) HASH(0x55b3d7e93820) HASH(0x55b3d7e860c0) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1\
ce1bec85e58b458386f8b7a0bedfaa6 e5ac68a0110cb43a3a0bc17d545ae7a0bd746ef9, results HASH(0x55b3d7e90290) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 c62748312e0adec0cbcf0f8d7d126080e5e43a82, results HASH(0x55b3d7e897d0) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\
0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 c805ceb0b26a643c7e47f01f2dbc50555d93cce8, results HASH(0x55b3d7e9db10) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 2d9b3699136d20e354a94daefebbeefa9ceec7b6, results HASH(0x55b3d7e894d0) HASH(0x55b3d7e877c8) Result found: flight 174814 (fail), \
for basis failure (at ancestor ~732)
Repro found: flight 174842 (pass), for basis pass
Repro found: flight 174843 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 b746458e1ce1bec85e58b458386f8b7a0bedfaa6 bd87315a603bf25e869e6293f7db7b1024d67999
No revisions left to test, checking graph state.
Result found: flight 174848 (pass), for last pass
Result found: flight 174849 (fail), for first failure
Repro found: flight 174850 (pass), for last pass
Repro found: flight 174851 (fail), for first failure
Repro found: flight 174853 (pass), for last pass
Repro found: flight 174855 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
Bug not present: bd87315a603bf25e869e6293f7db7b1024d67999
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/174855/
commit 7c3bbd940dd8aeb1649734e5055798cc6f3fea4e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Tue Oct 25 15:27:05 2022 +0100
xen/arm, libxl: Revert XEN_DOMCTL_shadow_op; use p2m mempool hypercalls
This reverts most of commit cf2a68d2ffbc3ce95e01449d46180bddb10d24a0, and bits
of cbea5a1149ca7fd4b7cdbfa3ec2e4f109b601ff7.
First of all, with ARM borrowing x86's implementation, the logic to set the
pool size should have been common, not duplicated. Introduce
libxl__domain_set_paging_mempool_size() as a shared implementation, and use it
from the ARM and x86 paths. It is left as an exercise to the reader to judge
how libxl/xl can reasonably function without the ability to query the pool
size...
Remove ARM's p2m_domctl() infrastructure now the functioanlity has been
replaced with a working and unit tested interface.
This is part of XSA-409 / CVE-2022-33747.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Release-acked-by: Henry Wang <Henry.Wang@arm.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
174855: tolerable ALL FAIL
flight 174855 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/174855/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2021-08-21 23:29 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2021-08-21 23:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
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: 6b1ca51b1a91d002636518afe4a8a50ba7212495
Bug not present: 4c0a19991465fc19c5afa9bc3f304bae6044314e
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/164318/
commit 6b1ca51b1a91d002636518afe4a8a50ba7212495
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Aug 18 09:40:08 2021 +0200
x86/PV: assert page state in mark_pv_pt_pages_rdonly()
About every time I look at dom0_construct_pv()'s "calculation" of
nr_pt_pages I question (myself) whether the result is precise or merely
an upper bound. I think it is meant to be precise, but I think we would
be better off having some checking in place. Hence add ASSERT()s to
verify that
- all pages have a valid L1...Ln (currently L4) page table type and
- no other bits are set, in particular the type refcount is still zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citirx.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.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-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot --summary-out=tmp/164318.bisection-summary --basis-template=164237 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm xen-boot
Searching for failure / basis pass:
164264 fail [host=huxelrebe1] / 164237 [host=chardonnay0] 164230 [host=huxelrebe0] 164171 [host=pinot1] 164154 [host=albana0] 164149 [host=elbling1] 164145 [host=albana1] 164129 [host=chardonnay0] 164123 [host=elbling0] 164119 ok.
Failure / basis pass flights: 164264 / 164119
(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 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 5293470a77ad980dce2af9b7e6c3f11eeebf1b64
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 2b45ff60301a988badec526846e77b538383ae63
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#136c34c9bc4179dc64b15b2bb5f0c54\
ca4ddf823-136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 git://xenbits.xen.org/xen.git#2b45ff60301a988badec526846e77b538383ae63-5293470a77ad980dce2af9b7e6c3f11eeebf1b64
Loaded 5001 nodes in revision graph
Searching for test results:
164116 [host=albana1]
164119 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 2b45ff60301a988badec526846e77b538383ae63
164123 [host=elbling0]
164129 [host=chardonnay0]
164145 [host=albana1]
164149 [host=elbling1]
164154 [host=albana0]
164171 [host=pinot1]
164230 [host=huxelrebe0]
164237 [host=chardonnay0]
164248 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 517a90d1ca09ce00e50d46ac25566cc3bd2eb34d
164264 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 5293470a77ad980dce2af9b7e6c3f11eeebf1b64
164294 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 2b45ff60301a988badec526846e77b538383ae63
164296 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 517a90d1ca09ce00e50d46ac25566cc3bd2eb34d
164303 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 60a9d8d2fc9c4a524c7342499580a88aaa3a2b55
164306 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b
164307 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 54c9736382e0d558a6acd820e44185e020131c48
164308 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4c0a19991465fc19c5afa9bc3f304bae6044314e
164310 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 5293470a77ad980dce2af9b7e6c3f11eeebf1b64
164313 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6b1ca51b1a91d002636518afe4a8a50ba7212495
164314 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4c0a19991465fc19c5afa9bc3f304bae6044314e
164315 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6b1ca51b1a91d002636518afe4a8a50ba7212495
164317 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4c0a19991465fc19c5afa9bc3f304bae6044314e
164318 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 6b1ca51b1a91d002636518afe4a8a50ba7212495
Searching for interesting versions
Result found: flight 164119 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4c0a19991465fc19c5afa9bc3f304bae6044314e, results HASH(0x55db81533920) HASH(0x55db81541048) HASH(0x55db8153d190) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9b\
c4179dc64b15b2bb5f0c54ca4ddf823 54c9736382e0d558a6acd820e44185e020131c48, results HASH(0x55db8152ab58) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 bc141e8ca56200bdd0a12e04a6ebff3c19d6c27b, results HASH(0x55db8153aa08) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\
0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 60a9d8d2fc9c4a524c7342499580a88aaa3a2b55, results HASH(0x55db81535ad0) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 2b45ff60301a988badec526846e77b538383ae63, results HASH(0x55db81531018) HASH(0x55db815295d0) Result found: flight 164248 (fail), \
for basis failure (at ancestor ~680)
Repro found: flight 164294 (pass), for basis pass
Repro found: flight 164310 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 136c34c9bc4179dc64b15b2bb5f0c54ca4ddf823 4c0a19991465fc19c5afa9bc3f304bae6044314e
No revisions left to test, checking graph state.
Result found: flight 164308 (pass), for last pass
Result found: flight 164313 (fail), for first failure
Repro found: flight 164314 (pass), for last pass
Repro found: flight 164315 (fail), for first failure
Repro found: flight 164317 (pass), for last pass
Repro found: flight 164318 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 6b1ca51b1a91d002636518afe4a8a50ba7212495
Bug not present: 4c0a19991465fc19c5afa9bc3f304bae6044314e
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/164318/
commit 6b1ca51b1a91d002636518afe4a8a50ba7212495
Author: Jan Beulich <jbeulich@suse.com>
Date: Wed Aug 18 09:40:08 2021 +0200
x86/PV: assert page state in mark_pv_pt_pages_rdonly()
About every time I look at dom0_construct_pv()'s "calculation" of
nr_pt_pages I question (myself) whether the result is precise or merely
an upper bound. I think it is meant to be precise, but I think we would
be better off having some checking in place. Hence add ASSERT()s to
verify that
- all pages have a valid L1...Ln (currently L4) page table type and
- no other bits are set, in particular the type refcount is still zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citirx.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
164318: tolerable ALL FAIL
flight 164318 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/164318/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 8 xen-boot fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2020-11-12 12:29 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2020-11-12 12:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: e19bcb626f50a652fb1854a8b2f2c9c371687a11
Bug not present: c3453a23f7905d24f2404787543e26ec7d02301c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/156714/
commit e19bcb626f50a652fb1854a8b2f2c9c371687a11
Author: Juergen Gross <jgross@suse.com>
Date: Fri Nov 6 10:48:07 2020 +0100
xen/rwlock: add check_lock() handling to rwlocks
Checking whether a lock is consistently used regarding interrupts on
or off is beneficial for rwlocks, too.
So add check_lock() calls to rwlock functions. For this purpose make
check_lock() globally accessible.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/156714.bisection-summary --basis-template=156443 --blessings=real,real-bisect,real-retry xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
156663 fail [host=huxelrebe0] / 156443 [host=fiano0] 156401 [host=albana0] 156389 [host=elbling1] 156373 [host=huxelrebe1] 156354 [host=albana1] 156339 [host=fiano1] 156331 [host=chardonnay1] 156315 [host=chardonnay0] 156291 [host=elbling0] 156268 [host=fiano1] 156254 [host=rimava1] 156248 [host=albana0] 156228 [host=albana1] 156196 [host=huxelrebe1] 156167 [host=pinot1] 156136 ok.
Failure / basis pass flights: 156663 / 156136
(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 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 6ca70821b59849ad97c3fadc47e63c1a4af1a78c
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-7ea428895af2840d85c524f0bd11a38aac308308 git://xenbits.xen.org/xen.git#6ca70821b59849ad97c3fadc47e63c1a4af1a78c-3059178798a23ba870ff86ff54d442a07e6651fc
Loaded 41918 nodes in revision graph
Searching for test results:
156119 [host=pinot0]
156136 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 6ca70821b59849ad97c3fadc47e63c1a4af1a78c
156167 [host=pinot1]
156196 [host=huxelrebe1]
156228 [host=albana1]
156248 [host=albana0]
156254 [host=rimava1]
156268 [host=fiano1]
156291 [host=elbling0]
156315 [host=chardonnay0]
156331 [host=chardonnay1]
156339 [host=fiano1]
156354 [host=albana1]
156373 [host=huxelrebe1]
156389 [host=elbling1]
156401 [host=albana0]
156443 [host=fiano0]
156524 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 2a5f9f6a6932214fda76b9b3c03e024772882d34
156538 fail irrelevant
156556 fail irrelevant
156577 fail irrelevant
156588 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
156608 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
156666 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 ea6d3cd1ed79d824e605a70c3626bc437c386260 6ca70821b59849ad97c3fadc47e63c1a4af1a78c
156691 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 0a5e0ce0fb7e5a3b5dfdc936058d2c0e04e5e258
156694 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 82c0d3d491ccb183cf12c87775086b68531b8444
156696 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd dac867bf9adc1562a4cf9db5f89726597af13ef8
156697 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 9ff9705647646aa937b5f5c1426a64c69a62b3bd
156698 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 957708c2d1ae25d7375abd5e5e70c3043d64f1f1
156701 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd c3453a23f7905d24f2404787543e26ec7d02301c
156706 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd e19bcb626f50a652fb1854a8b2f2c9c371687a11
156707 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd c3453a23f7905d24f2404787543e26ec7d02301c
156709 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd e19bcb626f50a652fb1854a8b2f2c9c371687a11
156663 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
156710 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd c3453a23f7905d24f2404787543e26ec7d02301c
156712 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 7ea428895af2840d85c524f0bd11a38aac308308 3059178798a23ba870ff86ff54d442a07e6651fc
156714 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd e19bcb626f50a652fb1854a8b2f2c9c371687a11
Searching for interesting versions
Result found: flight 156136 (pass), for basis pass
For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd c3453a23f7905d24f2404787543e26ec7d02301c, results HASH(0x56279bb52f80) HASH(0x56279bb48278) HASH(0x56279e97e650) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe132\
4c29294bb1d1b8454b3f214725e40fd 957708c2d1ae25d7375abd5e5e70c3043d64f1f1, results HASH(0x56279bb411e8) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 9ff9705647646aa937b5f5c1426a64c69a62b3bd, results HASH(0x56279e97f918) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f\
0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd dac867bf9adc1562a4cf9db5f89726597af13ef8, results HASH(0x56279e981200) For basis failure, parent search stopping at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd 82c0d3d491ccb183cf12c87775086b68531b8444, results HASH(0x56279e97ca98) Result found: flight 156524 (fail), for basis failure (at\
ancestor ~34)
Repro found: flight 156666 (pass), for basis pass
Repro found: flight 156712 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 677cbe1324c29294bb1d1b8454b3f214725e40fd c3453a23f7905d24f2404787543e26ec7d02301c
No revisions left to test, checking graph state.
Result found: flight 156701 (pass), for last pass
Result found: flight 156706 (fail), for first failure
Repro found: flight 156707 (pass), for last pass
Repro found: flight 156709 (fail), for first failure
Repro found: flight 156710 (pass), for last pass
Repro found: flight 156714 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: e19bcb626f50a652fb1854a8b2f2c9c371687a11
Bug not present: c3453a23f7905d24f2404787543e26ec7d02301c
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/156714/
commit e19bcb626f50a652fb1854a8b2f2c9c371687a11
Author: Juergen Gross <jgross@suse.com>
Date: Fri Nov 6 10:48:07 2020 +0100
xen/rwlock: add check_lock() handling to rwlocks
Checking whether a lock is consistently used regarding interrupts on
or off is beneficial for rwlocks, too.
So add check_lock() calls to rwlock functions. For this purpose make
check_lock() globally accessible.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
156714: tolerable ALL FAIL
flight 156714 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/156714/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2020-04-10 1:43 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2020-04-10 1:43 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: e013e8514389b739153016349e49f5a78e34ddf0
Bug not present: 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149585/
commit e013e8514389b739153016349e49f5a78e34ddf0
Author: Juergen Gross <jgross@suse.com>
Date: Tue Apr 7 15:48:31 2020 +0200
config: use mini-os master for unstable
We haven't used mini-os master for about 2 years now due to a stubdom
test failing [1]. Booting a guest with mini-os master used for building
stubdom didn't reveal any problem, so use master for unstable in order
to let OSStest find any problems not showing up in the local test.
[1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/149585.bisection-summary --basis-template=149478 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
149547 fail [host=huxelrebe1] / 149478 [host=elbling1] 149451 [host=debina0] 149431 [host=elbling0] 149406 [host=albana1] 149378 [host=debina1] 149297 [host=fiano0] 149260 [host=pinot1] 149231 [host=chardonnay0] 149188 [host=debina0] 149151 [host=fiano1] 149121 [host=chardonnay1] 149068 [host=albana0] 149029 [host=italia0] 148980 [host=huxelrebe0] 148925 ok.
Failure / basis pass flights: 149547 / 148925
(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 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
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#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef git://xenbits.xen.org/xen.git#60d6ba1916dce0622a53b00dbae3c01d0761057e-9be0b2747bc7381c684cfbdd3fa2e40badefbeef
Loaded 5001 nodes in revision graph
Searching for test results:
148826 [host=albana0]
148873 [host=rimava1]
148925 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
148980 [host=huxelrebe0]
149029 [host=italia0]
149068 [host=albana0]
149121 [host=chardonnay1]
149151 [host=fiano1]
149188 [host=debina0]
149231 [host=chardonnay0]
149260 [host=pinot1]
149297 [host=fiano0]
149335 []
149378 [host=debina1]
149406 [host=albana1]
149431 [host=elbling0]
149451 [host=debina0]
149478 [host=elbling1]
149502 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
149549 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 37053578e8bd57de9d114b19a29f5ab1533d6071
149537 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
149539 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 5af4698d98d881e786c0909b6308f04696586c49
149566 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
149520 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
149552 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 4853f03dee2ed17cc421260d669377db253f0dac
149541 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 98eb0c994ca828da7f38f0ee04c57a0ae24068a5
149521 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
149562 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 60d6ba1916dce0622a53b00dbae3c01d0761057e
149545 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 41cebdd1a6b5e880c768a4af69724851e6a06108
149557 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 6b8836aa65947e58ba2b58573cece03754ad68f6
149584 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
149547 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 9be0b2747bc7381c684cfbdd3fa2e40badefbeef
149561 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
149571 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
149574 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
149581 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
149585 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef e013e8514389b739153016349e49f5a78e34ddf0
Searching for interesting versions
Result found: flight 148925 (pass), for basis pass
Result found: flight 149547 (fail), for basis failure
Repro found: flight 149562 (pass), for basis pass
Repro found: flight 149566 (fail), for basis failure
0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 d0d8ad39ecb51cd7497cd524484fe09f50876798 933ebad2470a169504799a1d95b8e410bd9847ef 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
No revisions left to test, checking graph state.
Result found: flight 149561 (pass), for last pass
Result found: flight 149571 (fail), for first failure
Repro found: flight 149574 (pass), for last pass
Repro found: flight 149581 (fail), for first failure
Repro found: flight 149584 (pass), for last pass
Repro found: flight 149585 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: e013e8514389b739153016349e49f5a78e34ddf0
Bug not present: 990b6e38d93c6e60f9d81e8b71ddfd209fca00bd
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/149585/
commit e013e8514389b739153016349e49f5a78e34ddf0
Author: Juergen Gross <jgross@suse.com>
Date: Tue Apr 7 15:48:31 2020 +0200
config: use mini-os master for unstable
We haven't used mini-os master for about 2 years now due to a stubdom
test failing [1]. Booting a guest with mini-os master used for building
stubdom didn't reveal any problem, so use master for unstable in order
to let OSStest find any problems not showing up in the local test.
[1]: https://lists.xen.org/archives/html/minios-devel/2018-04/msg00015.html
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
149585: tolerable ALL FAIL
flight 149585 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/149585/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2018-04-04 9:19 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2018-04-04 9:19 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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: 55e0590e4bed56db0ea628826409572c94c54ebf
Bug not present: ca45928e46e300c5de70a779c2a84d1f0e77b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121764/
commit 55e0590e4bed56db0ea628826409572c94c54ebf
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Mar 27 17:20:50 2018 +0100
Config.mk: update mini-os commit
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install --summary-out=tmp/121764.bisection-summary --basis-template=121272 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
121721 fail [host=italia0] / 121307 [host=baroque0] 121272 [host=elbling0] 121059 [host=elbling1] 120988 [host=baroque1] 120943 [host=chardonnay0] 120859 [host=pinot0] 120253 [host=huxelrebe1] 120189 [host=pinot1] 120120 [host=chardonnay1] 120076 [host=chardonnay0] 120037 [host=fiano0] 120001 [host=elbling0] 119970 [host=huxelrebe0] 119879 [host=italia1] 119785 [host=baroque1] 119713 [host=pinot0] 119651 [host=huxelrebe1] 119592 [host=elbling1] 119521 [host=baroque0] 119451 ok.
Failure / basis pass flights: 121721 / 119451
(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 c44cfe06dfe2a5f54527e87a48c92a6595d070cc c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 641f9ce2fab1b85479c564d9b27dfeb18a93ed87
Basis pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 2b033e396f4fa0981bae1213cdacd15775655a97 24470b99c1671dca531c2cf5747eda2f8892ecbc
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#7f3bd8db99746a60bcae1ec4059a4756d19b63c2-c44cfe06dfe2a5f54527e87a48c92a6595d070cc git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60 git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-5c3fdee026a204a59cb392e43a313ab558de9682 git://xenbits.xen.org/xen.git#24470b99c1671dca531c2cf5747eda2f8892ecbc-641f9ce2fab1b85479c564d9b27dfeb18a93ed87
adhoc-revtuple-generator: tree discontiguous: linux-pvops
Loaded 5096 nodes in revision graph
Searching for test results:
119451 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 2b033e396f4fa0981bae1213cdacd15775655a97 24470b99c1671dca531c2cf5747eda2f8892ecbc
119521 [host=baroque0]
119592 [host=elbling1]
119651 [host=huxelrebe1]
119713 [host=pinot0]
119785 [host=baroque1]
119970 [host=huxelrebe0]
119879 [host=italia1]
120001 [host=elbling0]
120076 [host=chardonnay0]
120037 [host=fiano0]
120189 [host=pinot1]
120120 [host=chardonnay1]
120287 [host=pinot0]
120253 [host=huxelrebe1]
120405 [host=pinot0]
120626 [host=pinot0]
120767 [host=pinot0]
120859 [host=pinot0]
120943 [host=chardonnay0]
120988 [host=baroque1]
121059 [host=elbling1]
121272 [host=elbling0]
121307 [host=baroque0]
121322 fail irrelevant
121342 fail irrelevant
121404 fail irrelevant
121682 fail c44cfe06dfe2a5f54527e87a48c92a6595d070cc c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 6bbcb226cebac90f8ce5ac901e000bfd3ad783c5
121699 blocked irrelevant
121709 pass irrelevant
121719 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 2b033e396f4fa0981bae1213cdacd15775655a97 24470b99c1671dca531c2cf5747eda2f8892ecbc
121666 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 2b033e396f4fa0981bae1213cdacd15775655a97 24470b99c1671dca531c2cf5747eda2f8892ecbc
121737 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 9f5b0ce10b2895b4136c9e5c5ebd0aebac31ea98
121687 fail irrelevant
121731 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 73a10cb91a4e5c6f7049a78a12dcdea3460f0bd1
121713 pass irrelevant
121702 pass irrelevant
121717 pass irrelevant
121715 pass irrelevant
121740 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 4fd21cf4d1d1712c1d22f959dd88d7c8d129cc72
121724 fail c44cfe06dfe2a5f54527e87a48c92a6595d070cc c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 6bbcb226cebac90f8ce5ac901e000bfd3ad783c5
121729 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 3025581f3ad70c153db830d0d80377c294033f63
121726 blocked 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 b43501451733193b265de30fd79a764363a2a473
121721 fail c44cfe06dfe2a5f54527e87a48c92a6595d070cc c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 641f9ce2fab1b85479c564d9b27dfeb18a93ed87
121746 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 31286f7a38d65ee461f88282ffacb1de00238a49
121748 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 2b033e396f4fa0981bae1213cdacd15775655a97 24470b99c1671dca531c2cf5747eda2f8892ecbc
121751 fail c44cfe06dfe2a5f54527e87a48c92a6595d070cc c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 641f9ce2fab1b85479c564d9b27dfeb18a93ed87
121753 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 55e0590e4bed56db0ea628826409572c94c54ebf
121754 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 ca45928e46e300c5de70a779c2a84d1f0e77b8d2
121757 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 55e0590e4bed56db0ea628826409572c94c54ebf
121759 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 ca45928e46e300c5de70a779c2a84d1f0e77b8d2
121760 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 55e0590e4bed56db0ea628826409572c94c54ebf
121763 pass 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 ca45928e46e300c5de70a779c2a84d1f0e77b8d2
121764 fail 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 55e0590e4bed56db0ea628826409572c94c54ebf
Searching for interesting versions
Result found: flight 119451 (pass), for basis pass
Result found: flight 121721 (fail), for basis failure
Repro found: flight 121748 (pass), for basis pass
Repro found: flight 121751 (fail), for basis failure
0 revisions at 7f3bd8db99746a60bcae1ec4059a4756d19b63c2 c530a75c1e6a472b0eb9558310b518f0dfcd8860 c8ea0457495342c417c3dc033bba25148b279f60 5c3fdee026a204a59cb392e43a313ab558de9682 ca45928e46e300c5de70a779c2a84d1f0e77b8d2
No revisions left to test, checking graph state.
Result found: flight 121754 (pass), for last pass
Result found: flight 121757 (fail), for first failure
Repro found: flight 121759 (pass), for last pass
Repro found: flight 121760 (fail), for first failure
Repro found: flight 121763 (pass), for last pass
Repro found: flight 121764 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 55e0590e4bed56db0ea628826409572c94c54ebf
Bug not present: ca45928e46e300c5de70a779c2a84d1f0e77b8d2
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/121764/
commit 55e0590e4bed56db0ea628826409572c94c54ebf
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Mar 27 17:20:50 2018 +0100
Config.mk: update mini-os commit
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
pnmtopng: 161 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.{dot,ps,png,html,svg}.
----------------------------------------
121764: tolerable ALL FAIL
flight 121764 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/121764/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2017-03-02 10:42 ` Andrew Cooper
@ 2017-03-02 11:09 ` Daniel Kiper
0 siblings, 0 replies; 17+ messages in thread
From: Daniel Kiper @ 2017-03-02 11:09 UTC (permalink / raw)
To: Andrew Cooper; +Cc: xen-devel, jbeulich, Daniel Kiper
On Thu, Mar 02, 2017 at 10:42:57AM +0000, Andrew Cooper wrote:
> On 02/03/17 10:41, Daniel Kiper wrote:
> > On Wed, Mar 01, 2017 at 11:53:52PM +0000, osstest service owner wrote:
> >> branch xen-unstable
> >> xenbranch xen-unstable
> >> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> >> 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/106324/
> >>
> >>
> >> commit c5b9805bc1f793177779ae342c65fcc201a15a47
> >> Author: Daniel Kiper <daniel.kiper@oracle.com>
> >> Date: Wed Feb 22 14:38:06 2017 +0100
> >>
> >> efi: create new early memory allocator
> > Does anybody know why this still fails? Andrew applied a fix (workaround) for this yesterday.
>
> Bisection runs from before will still be running. Also, the fix hasn't
This is what I expected.
> passed staging yet.
Yep, I saw that.
Thanks for update.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2017-03-02 10:41 ` Daniel Kiper
@ 2017-03-02 10:42 ` Andrew Cooper
2017-03-02 11:09 ` Daniel Kiper
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Cooper @ 2017-03-02 10:42 UTC (permalink / raw)
To: Daniel Kiper, xen-devel; +Cc: daniel.kiper, jbeulich
On 02/03/17 10:41, Daniel Kiper wrote:
> On Wed, Mar 01, 2017 at 11:53:52PM +0000, osstest service owner wrote:
>> branch xen-unstable
>> xenbranch xen-unstable
>> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
>> 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/106324/
>>
>>
>> commit c5b9805bc1f793177779ae342c65fcc201a15a47
>> Author: Daniel Kiper <daniel.kiper@oracle.com>
>> Date: Wed Feb 22 14:38:06 2017 +0100
>>
>> efi: create new early memory allocator
> Does anybody know why this still fails? Andrew applied a fix (workaround) for this yesterday.
Bisection runs from before will still be running. Also, the fix hasn't
passed staging yet.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
2017-03-01 23:53 osstest service owner
@ 2017-03-02 10:41 ` Daniel Kiper
2017-03-02 10:42 ` Andrew Cooper
0 siblings, 1 reply; 17+ messages in thread
From: Daniel Kiper @ 2017-03-02 10:41 UTC (permalink / raw)
To: xen-devel; +Cc: andrew.cooper3, daniel.kiper, jbeulich
On Wed, Mar 01, 2017 at 11:53:52PM +0000, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> 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/106324/
>
>
> commit c5b9805bc1f793177779ae342c65fcc201a15a47
> Author: Daniel Kiper <daniel.kiper@oracle.com>
> Date: Wed Feb 22 14:38:06 2017 +0100
>
> efi: create new early memory allocator
Does anybody know why this still fails? Andrew applied a fix (workaround) for this yesterday.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2017-03-01 23:53 osstest service owner
2017-03-02 10:41 ` Daniel Kiper
0 siblings, 1 reply; 17+ messages in thread
From: osstest service owner @ 2017-03-01 23:53 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
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/106324/
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-xl-qemut-stubdom-debianhvm-amd64-xsm.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-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot --summary-out=tmp/106324.bisection-summary --basis-template=105933 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm xen-boot
Searching for failure / basis pass:
106283 fail [host=elbling1] / 106160 [host=italia1] 106138 [host=nocera1] 106122 [host=merlot1] 106102 [host=huxelrebe0] 106081 [host=fiano1] 105994 [host=merlot0] 105966 [host=nobling0] 105946 [host=nocera0] 105933 [host=baroque0] 105919 [host=rimava0] 105900 [host=fiano0] 105896 [host=pinot0] 105873 [host=huxelrebe1] 105861 [host=nobling1] 105840 [host=chardonnay1] 105821 [host=elbling0] 105804 [host=huxelrebe0] 105790 [host=italia1] 105784 [host=chardonnay0] 105766 [host=pinot1] 105756 ok.
Failure / basis pass flights: 106283 / 105756
(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 8222557798768995e81c53aee3c273ea9503afb5
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 728e90b41d46c1c1c210ac496204efd51936db75 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#728e90b41d46c1c1c210ac496204efd51936db75-57e8fbb2f702001a18bd81e9fe31b26d94247ac9 git://xenbits.xen.org/xen.git#6f6d3b10ec8168e2a78cf385d89803397f116397-8222557798768995e81c53aee3c273ea9503afb5
Loaded 7004 nodes in revision graph
Searching for test results:
105707 [host=merlot1]
105728 [host=nocera1]
105790 [host=italia1]
105756 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 728e90b41d46c1c1c210ac496204efd51936db75 6f6d3b10ec8168e2a78cf385d89803397f116397
105742 [host=nobling0]
105784 [host=chardonnay0]
105766 [host=pinot1]
105804 [host=huxelrebe0]
105821 [host=elbling0]
105840 [host=chardonnay1]
105896 [host=pinot0]
105919 [host=rimava0]
105861 [host=nobling1]
105873 [host=huxelrebe1]
105900 [host=fiano0]
105933 [host=baroque0]
105946 [host=nocera0]
105966 [host=nobling0]
105994 [host=merlot0]
106102 [host=huxelrebe0]
106081 [host=fiano1]
106122 [host=merlot1]
106138 [host=nocera1]
106160 [host=italia1]
106289 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 728e90b41d46c1c1c210ac496204efd51936db75 6f6d3b10ec8168e2a78cf385d89803397f116397
106186 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 1f24be6c945c8f8e25547aed4a56c092133df713
106218 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 12f687bf28e23fa662bb518311c4ec71e5b39ab8
106261 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 12f687bf28e23fa662bb518311c4ec71e5b39ab8
106292 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 12f687bf28e23fa662bb518311c4ec71e5b39ab8
106299 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 2c31b07ec74a29a81fdc278256c3517ae724f5e9
106283 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 8222557798768995e81c53aee3c273ea9503afb5
106293 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe e88462aaa2f19e1238e77c1bcebbab7ef5380d7a 71af7d4220227529ea43b898683d4d2e68a90ffd
106300 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc 78da0c2a7a9c621ba64e515528e11e5f28f15050
106303 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 08c008de9c7d3ac71f71c87cc04a47819ca228dc b908131167a67a16fbe9c7a7826b67e2d93d9ec5
106305 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8b4834ee1202852ed83a9fc61268c65fb6961ea7 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 8222557798768995e81c53aee3c273ea9503afb5
106306 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 24682c89d05c997115555f02ec280f82ea24cef2
106309 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106313 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
106317 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106319 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
106321 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
106324 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 c5b9805bc1f793177779ae342c65fcc201a15a47
Searching for interesting versions
Result found: flight 105756 (pass), for basis pass
Result found: flight 106283 (fail), for basis failure
Repro found: flight 106289 (pass), for basis pass
Repro found: flight 106305 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b669e922b37b8957248798a5eb7aa96a666cd3fe 57e8fbb2f702001a18bd81e9fe31b26d94247ac9 b199c44afa3a0d18d0e968e78a590eb9e69e20ad
No revisions left to test, checking graph state.
Result found: flight 106309 (pass), for last pass
Result found: flight 106313 (fail), for first failure
Repro found: flight 106317 (pass), for last pass
Repro found: flight 106319 (fail), for first failure
Repro found: flight 106321 (pass), for last pass
Repro found: flight 106324 (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/106324/
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: 184 colors found
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-boot.{dot,ps,png,html,svg}.
----------------------------------------
106324: tolerable ALL FAIL
flight 106324 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/106324/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
@ 2016-01-15 1:42 osstest service owner
0 siblings, 0 replies; 17+ messages in thread
From: osstest service owner @ 2016-01-15 1:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid xen-install
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: 529298fdf9097f8e637f754c9b29bd58a8a714e9
Bug not present: 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/78130/
commit 529298fdf9097f8e637f754c9b29bd58a8a714e9
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:36:33 2016 +0100
convert FLASK_ENABLE to Kconfig
Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.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-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install --summary-out=tmp/78130.bisection-summary --basis-template=77892 --blessings=real,real-bisect xen-unstable test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm xen-install
Searching for failure / basis pass:
78008 fail [host=nocera1] / 77892 ok.
Failure / basis pass flights: 78008 / 77892
(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 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
Basis pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad f7347a282420a5edc74afb31e7c42c2765f24de5
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#5d7b0fcc26d66db767a477574effc764022c19ac-5d7b0fcc26d66db767a477574effc764022c19ac git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#569eac99e8ddccd15fe78e8a3af5622afe780e3b-569eac99e8ddccd15fe78e8a3af5622afe780e3b git://xenbits.xen.org/qemu-xen.git#f165e581d9a6f7cf81aa7496d3eee1e31212c8ad-f165e581d9a6f7cf81aa7496d3eee1e31212c8ad git://xenbits.xen.org/xen.git#f7347a282420a5edc74afb31e7c42c2765f24de5-20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
Loaded 1001 nodes in revision graph
Searching for test results:
77892 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad f7347a282420a5edc74afb31e7c42c2765f24de5
77827 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad f7347a282420a5edc74afb31e7c42c2765f24de5
78008 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
78007 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad f7347a282420a5edc74afb31e7c42c2765f24de5
77945 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
78119 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
78070 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 20c8f1a8a5fd61cb6f0ba6f3c3b3d567b1765116
78075 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 5513bd0b4675e2fa2ff4e9a06885f16727901805
78122 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 529298fdf9097f8e637f754c9b29bd58a8a714e9
78116 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 529298fdf9097f8e637f754c9b29bd58a8a714e9
78079 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
78126 pass 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
78130 fail 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 529298fdf9097f8e637f754c9b29bd58a8a714e9
Searching for interesting versions
Result found: flight 77827 (pass), for basis pass
Result found: flight 77945 (fail), for basis failure
Repro found: flight 78007 (pass), for basis pass
Repro found: flight 78008 (fail), for basis failure
0 revisions at 5d7b0fcc26d66db767a477574effc764022c19ac c530a75c1e6a472b0eb9558310b518f0dfcd8860 569eac99e8ddccd15fe78e8a3af5622afe780e3b f165e581d9a6f7cf81aa7496d3eee1e31212c8ad 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
No revisions left to test, checking graph state.
Result found: flight 78079 (pass), for last pass
Result found: flight 78116 (fail), for first failure
Repro found: flight 78119 (pass), for last pass
Repro found: flight 78122 (fail), for first failure
Repro found: flight 78126 (pass), for last pass
Repro found: flight 78130 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 529298fdf9097f8e637f754c9b29bd58a8a714e9
Bug not present: 361b4f9f0f0d4adc19df428e224a7b8fa62cd392
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/78130/
commit 529298fdf9097f8e637f754c9b29bd58a8a714e9
Author: Doug Goldstein <cardoe@cardoe.com>
Date: Tue Jan 12 11:36:33 2016 +0100
convert FLASK_ENABLE to Kconfig
Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Revision graph left in /home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.xen-install.{dot,ps,png,html,svg}.
----------------------------------------
78130: tolerable ALL FAIL
flight 78130 xen-unstable real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/78130/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 xen-install fail baseline untested
jobs:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 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] 17+ messages in thread
end of thread, other threads:[~2023-12-10 19:12 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-30 4:29 [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm osstest service owner
2016-10-30 16:53 ` Andrew Cooper
2016-10-31 15:00 ` Wei Liu
2016-10-30 17:31 ` Andrew Cooper
2016-10-31 10:31 ` Ian Jackson
2016-10-31 10:37 ` Andrew Cooper
-- strict thread matches above, loose matches on Subject: below --
2023-12-10 19:11 osstest service owner
2022-11-20 8:28 osstest service owner
2021-08-21 23:29 osstest service owner
2020-11-12 12:29 osstest service owner
2020-04-10 1:43 osstest service owner
2018-04-04 9:19 osstest service owner
2017-03-01 23:53 osstest service owner
2017-03-02 10:41 ` Daniel Kiper
2017-03-02 10:42 ` Andrew Cooper
2017-03-02 11:09 ` Daniel Kiper
2016-01-15 1:42 osstest service owner
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.