From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [xen-4.6-testing bisection] complete test-amd64-i386-rumprun-i386
Date: Sat, 01 Apr 2017 17:07:04 +0000 [thread overview]
Message-ID: <E1cuMUS-0001bd-JV@osstest.test-lab.xenproject.org> (raw)
branch xen-4.6-testing
xenbranch xen-4.6-testing
job test-amd64-i386-rumprun-i386
testid guest-destroy
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: rumprun git://xenbits.xen.org/osstest/rumprun.git
Tree: rumprun_buildrumpsh https://github.com/rumpkernel/buildrump.sh
Tree: rumprun_netbsdsrc https://github.com/rumpkernel/src-netbsd
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: 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Bug not present: 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107080/
commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Mar 31 09:03:32 2017 +0200
xen: sched: don't call hooks of the wrong scheduler via VCPU2OP
Within context_saved(), we call the context_saved hook,
and we use VCPU2OP() to determine from what scheduler.
VCPU2OP uses DOM2OP, which uses d->cpupool, which is
NULL when d is the idle domain. And in that case,
DOM2OP just returns ops, the scheduler of cpupool0.
Therefore, if:
- cpupool0's scheduler defines context_saved (like
Credit2 and RTDS do),
- we are not in cpupool0 (i.e., our scheduler is
not ops),
- we are context switching from idle,
we call VCPU2OP(idle_vcpu), which means
DOM2OP(idle->cpupool), which is ops.
Therefore, we both:
- check if context_saved is defined in the wrong
scheduler;
- if yes, call the wrong one.
When using Credit2 at boot, and also Credit2 in
the other cpupool, this is wrong but innocuous,
because it only involves the idle vcpus.
When using Credit2 at boot, and Credit1 in the
other cpupool, this is *totally* wrong, and
it's by chance it does not explode!
When using Credit2 and other schedulers I'm
developping, I hit the following assert (in
sched_credit2.c, on a CPU inside a cpupool that
does not use Credit2):
csched2_context_saved()
{
...
ASSERT(!vcpu_on_runq(svc));
...
}
Fix this by dealing explicitly, in VCPU2OP, with
idle vcpus, returning the scheduler of the pCPU
they (always) run on.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: a3653e6a279213ba4e883b2252415dc98633106a
master date: 2017-03-27 14:28:05 +0100
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.6-testing/test-amd64-i386-rumprun-i386.guest-destroy.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-4.6-testing/test-amd64-i386-rumprun-i386.guest-destroy --summary-out=tmp/107080.bisection-summary --basis-template=106819 --blessings=real,real-bisect xen-4.6-testing test-amd64-i386-rumprun-i386 guest-destroy
Searching for failure / basis pass:
107042 fail [host=huxelrebe0] / 106819 [host=italia1] 106663 [host=italia0] 106529 [host=elbling0] 105991 [host=pinot1] 105936 [host=italia0] 105831 [host=rimava1] 105816 [host=fiano0] 105685 ok.
Failure / basis pass flights: 107042 / 105685
(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: rumprun git://xenbits.xen.org/osstest/rumprun.git
Tree: rumprun_buildrumpsh https://github.com/rumpkernel/buildrump.sh
Tree: rumprun_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a7fd3717d99944530b04130f050e83402e64afed ba9175c5bde6796851d3b9d888ee488fd0257d05 39a97f37a85e44c69b662f6b97b688fbe892603b 21c6286247478dd186426b7be0c36534525ad6c9 b8b951e911a2fc555848a2785a9998bc128530b6 576f319a804bce8c9a7fb70a042f873f5eaf0151
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#a7fd3717d99944530b04130f050e83402e64afed-57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 git://xenbits.xen.org/qemu-xen.git#ba9175c5bde6796851d3b9d888ee488fd0257d05-44f3d4e6448e37588248db784193b7a047add65a git://xenbits.xen.org/osstest/rumprun.git#39a97f37a85e44c69b662f6b97b688fbe892603b-c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 https://github.com/rumpkernel/buildrump.sh#21c6286247478dd186426b7be0c36534525ad6c9-9c9b022cb2115734935e50600c867a3bc230b32c https://github.com/rumpkernel/src-netbsd#b8b951e911a2fc555848a2785a9998bc128530b6-b8b951e911a2fc555848a2785a9998bc128530b6 git://xenbits.xen.org/xen.git#576f319a804bce8c9a7fb70a042f873f5eaf0151-7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Loaded 61800 nodes in revision graph
Searching for test results:
105664 [host=chardonnay0]
105685 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a7fd3717d99944530b04130f050e83402e64afed ba9175c5bde6796851d3b9d888ee488fd0257d05 39a97f37a85e44c69b662f6b97b688fbe892603b 21c6286247478dd186426b7be0c36534525ad6c9 b8b951e911a2fc555848a2785a9998bc128530b6 576f319a804bce8c9a7fb70a042f873f5eaf0151
105673 [host=chardonnay0]
105816 [host=fiano0]
105831 [host=rimava1]
105936 [host=italia0]
105991 [host=pinot1]
106529 [host=elbling0]
106663 [host=italia0]
106819 [host=italia1]
107067 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 ac4c5d4ddf89051365da2acba5c6c306a10e0bbe
107020 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107080 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107051 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 3c157b590cdf429369f7bd8962682728febad6f1 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 18949dc6e1a520b6430f128a6981318552ca7823
107071 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 4f9617120b09ad1554d8e4a0ca817e27bfbbe1a1
107072 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 541ad61a921965c692ea31a06d9d14a1bb1e7346
107042 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107058 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 39a97f37a85e44c69b662f6b97b688fbe892603b fcc8f253edbd0c4e8b2705d412c6d84dda4f389b b8b951e911a2fc555848a2785a9998bc128530b6 b0577dd0c600241abcaddeb8d75abb0d956fdae3
107073 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
107040 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a7fd3717d99944530b04130f050e83402e64afed ba9175c5bde6796851d3b9d888ee488fd0257d05 39a97f37a85e44c69b662f6b97b688fbe892603b 21c6286247478dd186426b7be0c36534525ad6c9 b8b951e911a2fc555848a2785a9998bc128530b6 576f319a804bce8c9a7fb70a042f873f5eaf0151
107062 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 39a97f37a85e44c69b662f6b97b688fbe892603b 289ee221e4b777cbb7db1a084b596fc2c88fde04 b8b951e911a2fc555848a2785a9998bc128530b6 b0577dd0c600241abcaddeb8d75abb0d956fdae3
107049 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107065 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 b7e9d3976ba48f277da6004311f5025b07a884ea 722ce03b32f37ef5af09105727b574339326d354 e5207b247d4d87f68a91ae3e03d600d2a6265177 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 18949dc6e1a520b6430f128a6981318552ca7823
107074 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107077 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
107078 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
107079 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
Searching for interesting versions
Result found: flight 105685 (pass), for basis pass
Result found: flight 107020 (fail), for basis failure
Repro found: flight 107040 (pass), for basis pass
Repro found: flight 107042 (fail), for basis failure
0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 c530a75c1e6a472b0eb9558310b518f0dfcd8860 57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 44f3d4e6448e37588248db784193b7a047add65a c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74 9c9b022cb2115734935e50600c867a3bc230b32c b8b951e911a2fc555848a2785a9998bc128530b6 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
No revisions left to test, checking graph state.
Result found: flight 107073 (pass), for last pass
Result found: flight 107074 (fail), for first failure
Repro found: flight 107077 (pass), for last pass
Repro found: flight 107078 (fail), for first failure
Repro found: flight 107079 (pass), for last pass
Repro found: flight 107080 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Bug not present: 7017321d9b7b23adb50cad66d55ae526ab5d9fe1
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107080/
commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri Mar 31 09:03:32 2017 +0200
xen: sched: don't call hooks of the wrong scheduler via VCPU2OP
Within context_saved(), we call the context_saved hook,
and we use VCPU2OP() to determine from what scheduler.
VCPU2OP uses DOM2OP, which uses d->cpupool, which is
NULL when d is the idle domain. And in that case,
DOM2OP just returns ops, the scheduler of cpupool0.
Therefore, if:
- cpupool0's scheduler defines context_saved (like
Credit2 and RTDS do),
- we are not in cpupool0 (i.e., our scheduler is
not ops),
- we are context switching from idle,
we call VCPU2OP(idle_vcpu), which means
DOM2OP(idle->cpupool), which is ops.
Therefore, we both:
- check if context_saved is defined in the wrong
scheduler;
- if yes, call the wrong one.
When using Credit2 at boot, and also Credit2 in
the other cpupool, this is wrong but innocuous,
because it only involves the idle vcpus.
When using Credit2 at boot, and Credit1 in the
other cpupool, this is *totally* wrong, and
it's by chance it does not explode!
When using Credit2 and other schedulers I'm
developping, I hit the following assert (in
sched_credit2.c, on a CPU inside a cpupool that
does not use Credit2):
csched2_context_saved()
{
...
ASSERT(!vcpu_on_runq(svc));
...
}
Fix this by dealing explicitly, in VCPU2OP, with
idle vcpus, returning the scheduler of the pCPU
they (always) run on.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
master commit: a3653e6a279213ba4e883b2252415dc98633106a
master date: 2017-03-27 14:28:05 +0100
Revision graph left in /home/logs/results/bisect/xen-4.6-testing/test-amd64-i386-rumprun-i386.guest-destroy.{dot,ps,png,html,svg}.
----------------------------------------
107080: tolerable FAIL
flight 107080 xen-4.6-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/107080/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-rumprun-i386 12 guest-destroy fail baseline untested
jobs:
build-i386-rumprun pass
test-amd64-i386-rumprun-i386 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
reply other threads:[~2017-04-01 17:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1cuMUS-0001bd-JV@osstest.test-lab.xenproject.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).