[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-4.6-testing bisection] complete test-xtf-amd64-amd64-3



branch xen-4.6-testing
xenbranch xen-4.6-testing
job test-xtf-amd64-amd64-3
testid xtf-fep

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
Tree: xtf git://xenbits.xen.org/xtf.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/107099/


  commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
  Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
      Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
      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-xtf-amd64-amd64-3.xtf-fep.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-xtf-amd64-amd64-3.xtf-fep
 --summary-out=tmp/107099.bisection-summary --basis-template=106819 
--blessings=real,real-bisect xen-4.6-testing test-xtf-amd64-amd64-3 xtf-fep
Searching for failure / basis pass:
 107076 fail [host=huxelrebe0] / 106819 [host=baroque1] 106663 [host=godello1] 
106529 [host=chardonnay0] 105991 [host=godello1] 105936 [host=italia0] 105831 
[host=elbling1] 105816 [host=elbling0] 105685 [host=fiano0] 105673 
[host=merlot1] 105664 [host=chardonnay0] 104570 [host=nobling1] 104308 
[host=baroque0] 104278 [host=baroque1] 104251 [host=godello1] 103795 
[host=godello1] 103407 ok.
Failure / basis pass flights: 107076 / 103407
(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
Tree: xtf git://xenbits.xen.org/xtf.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a7fd3717d99944530b04130f050e83402e64afed 
ba9175c5bde6796851d3b9d888ee488fd0257d05 
ac699ed4c45a4ea4f93d366b9185d62795ffdf48 
1f021c88130b4d2d818ba4f269b3929339c00a88
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/xen.git#ac699ed4c45a4ea4f93d366b9185d62795ffdf48-7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
 
git://xenbits.xen.org/xtf.git#1f021c88130b4d2d818ba4f269b3929339c00a88-2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 465.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 465.
Loaded 3128 nodes in revision graph
Searching for test results:
 103407 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a7fd3717d99944530b04130f050e83402e64afed 
ba9175c5bde6796851d3b9d888ee488fd0257d05 
ac699ed4c45a4ea4f93d366b9185d62795ffdf48 
1f021c88130b4d2d818ba4f269b3929339c00a88
 103323 [host=italia1]
 103795 [host=godello1]
 104251 [host=godello1]
 104308 [host=baroque0]
 104278 [host=baroque1]
 104364 []
 104387 []
 104424 []
 104444 []
 104512 []
 104541 []
 104570 [host=nobling1]
 105664 [host=chardonnay0]
 105685 [host=fiano0]
 105673 [host=merlot1]
 105816 [host=elbling0]
 105831 [host=elbling1]
 105936 [host=italia0]
 105991 [host=godello1]
 106529 [host=chardonnay0]
 106663 [host=godello1]
 106819 [host=baroque1]
 107020 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107087 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b7e9d3976ba48f277da6004311f5025b07a884ea 
722ce03b32f37ef5af09105727b574339326d354 
ef5eb089442532c7eb7d2fb428607acf7088b9f8 
83af19a3154af85815e4c8ffd170839b99685adc
 107081 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a7fd3717d99944530b04130f050e83402e64afed 
ba9175c5bde6796851d3b9d888ee488fd0257d05 
ac699ed4c45a4ea4f93d366b9185d62795ffdf48 
1f021c88130b4d2d818ba4f269b3929339c00a88
 107042 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107098 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7017321d9b7b23adb50cad66d55ae526ab5d9fe1 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107082 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107093 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7017321d9b7b23adb50cad66d55ae526ab5d9fe1 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107096 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107083 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
a7fd3717d99944530b04130f050e83402e64afed 
ba9175c5bde6796851d3b9d888ee488fd0257d05 
163543ac31e90bdc7da589c63c5a997004ee11c9 
c92015f8ab00026f85d187d0090fc02e8ab4cfaf
 107089 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
ac4c5d4ddf89051365da2acba5c6c306a10e0bbe 
83af19a3154af85815e4c8ffd170839b99685adc
 107086 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b7e9d3976ba48f277da6004311f5025b07a884ea 
722ce03b32f37ef5af09105727b574339326d354 
e9fbb8eb834b21a6f0ed18f41e35baa74ada3205 
a2b8a3f25558792e5956b960c6fa52698da811b0
 107076 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107094 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107091 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
4f9617120b09ad1554d8e4a0ca817e27bfbbe1a1 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107092 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
541ad61a921965c692ea31a06d9d14a1bb1e7346 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107099 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
 107095 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7017321d9b7b23adb50cad66d55ae526ab5d9fe1 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
Searching for interesting versions
 Result found: flight 103407 (pass), for basis pass
 Result found: flight 107020 (fail), for basis failure
 Repro found: flight 107081 (pass), for basis pass
 Repro found: flight 107082 (fail), for basis failure
 0 revisions at b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
57ca3f4a3092695dd553d3ff4540f5559b1c8fc7 
44f3d4e6448e37588248db784193b7a047add65a 
7017321d9b7b23adb50cad66d55ae526ab5d9fe1 
2b62f68c373159b0b4b0c24512ebfbc8fb02f58e
No revisions left to test, checking graph state.
 Result found: flight 107093 (pass), for last pass
 Result found: flight 107094 (fail), for first failure
 Repro found: flight 107095 (pass), for last pass
 Repro found: flight 107096 (fail), for first failure
 Repro found: flight 107098 (pass), for last pass
 Repro found: flight 107099 (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/107099/


  commit 7ff6d9fc19ef88d2ca3304a312c0e8a46b61f546
  Author: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
      Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>
      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-xtf-amd64-amd64-3.xtf-fep.{dot,ps,png,html,svg}.
----------------------------------------
107099: tolerable truncated

flight 107099 xen-4.6-testing real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/107099/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-xtf-amd64-amd64-3       10 xtf-fep                 fail baseline untested


jobs:
 test-xtf-amd64-amd64-3                                       truncated


------------------------------------------------------------
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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.