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

[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm



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@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Acked-by: David Scott <dave@xxxxxxxxxx>
      Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>


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@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Acked-by: David Scott <dave@xxxxxxxxxx>
      Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>

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@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®.