Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Xen>
  3. Devel
[xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
ian.jackson at eu
Feb 24, 2012, 4:56 PM
Post #1 of 7 (154 views)
Permalink
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test redhat-install

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg

*** Found and reproduced problem changeset ***

Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: a59c1dcfe968
Bug not present: f9789db96c39


changeset: 24875:a59c1dcfe968
user: Justin T. Gibbs <justing@spectralogic.com>
date: Thu Feb 23 10:03:07 2012 +0000

blkif.h: Define and document the request number/size/segments extension

Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
BLKIF_MAX_SEGMENTS_PER_REQUEST has changed. Drivers must be
updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
before being recompiled with a __XEN_INTERFACE_VERSION greater
than or equal to this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
Committed-by: Keir Fraser <keir@xen.org>




For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
12043 fail [host=potato-beetle] / 12031 ok.
Failure / basis pass flights: 12043 / 12031
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b95c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 59 nodes in revision graph
Searching for test results:
12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
Searching for interesting versions
Result found: flight 12024 (pass), for basis pass
Result found: flight 12043 (fail), for basis failure
Repro found: flight 12044 (pass), for basis pass
Repro found: flight 12054 (fail), for basis failure
0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad 128de2549c5f24e4a437b86bd2e46f023976d50a 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
No revisions left to test, checking graph state.
Result found: flight 12051 (pass), for last pass
Result found: flight 12052 (fail), for first failure
Repro found: flight 12055 (pass), for last pass
Repro found: flight 12057 (fail), for first failure
Repro found: flight 12059 (pass), for last pass
Repro found: flight 12060 (fail), for first failure

*** Found and reproduced problem changeset ***

Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: a59c1dcfe968
Bug not present: f9789db96c39

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

changeset: 24875:a59c1dcfe968
user: Justin T. Gibbs <justing@spectralogic.com>
date: Thu Feb 23 10:03:07 2012 +0000

blkif.h: Define and document the request number/size/segments extension

Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
BLKIF_MAX_SEGMENTS_PER_REQUEST has changed. Drivers must be
updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
before being recompiled with a __XEN_INTERFACE_VERSION greater
than or equal to this value.

This extension first appeared in the FreeBSD Operating System.

Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
Committed-by: Keir Fraser <keir@xen.org>



Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.redhat-install.{dot,ps,png,html}.
----------------------------------------
12060: ALL FAIL

flight 12060 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/


jobs:
test-amd64-i386-rhel6hvm-amd fail


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
JBeulich at suse
Feb 27, 2012, 1:03 AM
Post #2 of 7 (140 views)
Permalink
>>> On 25.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-amd64-i386-rhel6hvm-amd
> test redhat-install
>
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
>
> *** Found and reproduced problem changeset ***

I had warned a number of times that a change like this should not be
done: Afaict, this broke qemu-xen (and upstream qemu as well), which
use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
specific __XEN_INTERFACE_VERSION__ (the tools generally just use
'latest').

The same would go for tools/blktap*/.

So either all uses within tools land get properly fixed (which is going to
be particularly hard to synchronize with upstream qemu), or (my
preference) the change gets reverted and done backward
compatibly without involving __XEN_INTERFACE_VERSION__.

Jan

> Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Bug introduced: a59c1dcfe968
> Bug not present: f9789db96c39
>
>
> changeset: 24875:a59c1dcfe968
> user: Justin T. Gibbs <justing@spectralogic.com>
> date: Thu Feb 23 10:03:07 2012 +0000
>
> blkif.h: Define and document the request number/size/segments
> extension
>
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has changed. Drivers must be
> updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
> before being recompiled with a __XEN_INTERFACE_VERSION greater
> than or equal to this value.
>
> This extension first appeared in the FreeBSD Operating System.
>
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> Committed-by: Keir Fraser <keir@xen.org>
>
>
>
>
> For bisection revision-tuple graph see:
>
> http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-
> amd64-i386-rhel6hvm-amd.redhat-install.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
>
> ----------------------------------------
> Searching for failure / basis pass:
> 12043 fail [host=potato-beetle] / 12031 ok.
> Failure / basis pass flights: 12043 / 12031
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Latest 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> Basis pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> Generating revisions with ./adhoc-revtuple-generator
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#1aaf53ee291d9e71
> d6ec05c0ebdb2854fea175ad-1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> git://xenbits.xen.org/staging/qemu-xen-unstable.git#128de2549c5f24e4a437b86bd2e
> 46f023976d50a-128de2549c5f24e4a437b86bd2e46f023976d50a
> git://xenbits.xen.org/staging/qemu-upstream-unstable.git#86a8d63bc11431509506b9
> 5c1481e1a023302cbc-86a8d63bc11431509506b95c1481e1a023302cbc
> http://xenbits.xen.org/staging/xen-unstable.hg#a4d93d0e0df2-0c3d19f40ab1
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> Loaded 59 nodes in revision graph
> Searching for test results:
> 12031 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> 12024 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> 12043 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> 12035 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
> 12044 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a4d93d0e0df2
> 12047 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc adcd6ab160fa
> 12049 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc 7cf234b198a3
> 12050 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc 4e1460cd2227
> 12051 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> 12052 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> 12054 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc 0c3d19f40ab1
> 12055 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> 12056 blocked 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> 12057 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> 12059 pass 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> 12060 fail 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc a59c1dcfe968
> Searching for interesting versions
> Result found: flight 12024 (pass), for basis pass
> Result found: flight 12043 (fail), for basis failure
> Repro found: flight 12044 (pass), for basis pass
> Repro found: flight 12054 (fail), for basis failure
> 0 revisions at 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
> 128de2549c5f24e4a437b86bd2e46f023976d50a
> 86a8d63bc11431509506b95c1481e1a023302cbc f9789db96c39
> No revisions left to test, checking graph state.
> Result found: flight 12051 (pass), for last pass
> Result found: flight 12052 (fail), for first failure
> Repro found: flight 12055 (pass), for last pass
> Repro found: flight 12057 (fail), for first failure
> Repro found: flight 12059 (pass), for last pass
> Repro found: flight 12060 (fail), for first failure
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Bug introduced: a59c1dcfe968
> Bug not present: f9789db96c39
>
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
>
> changeset: 24875:a59c1dcfe968
> user: Justin T. Gibbs <justing@spectralogic.com>
> date: Thu Feb 23 10:03:07 2012 +0000
>
> blkif.h: Define and document the request number/size/segments
> extension
>
> Note: As of __XEN_INTERFACE_VERSION__ 0x00040201 the definition of
> BLKIF_MAX_SEGMENTS_PER_REQUEST has changed. Drivers must be
> updated to, at minimum, use BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK,
> before being recompiled with a __XEN_INTERFACE_VERSION greater
> than or equal to this value.
>
> This extension first appeared in the FreeBSD Operating System.
>
> Signed-off-by: Justin T. Gibbs <justing@spectralogic.com>
> Committed-by: Keir Fraser <keir@xen.org>
>
>
>
> Revision graph left in
> /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.re
> dhat-install.{dot,ps,png,html}.
> ----------------------------------------
> 12060: ALL FAIL
>
> flight 12060 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/12060/
>
>
> jobs:
> test-amd64-i386-rhel6hvm-amd fail
>
>
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
>
> Logs, config files, etc. are available at
> http://www.chiark.greenend.org.uk/~xensrcts/logs
>
> Test harness code can be found at
> http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
Ian.Campbell at citrix
Feb 27, 2012, 1:32 AM
Post #3 of 7 (141 views)
Permalink
On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
> >>> On 25.02.12 at 01:56, xen.org <ian.jackson@eu.citrix.com> wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-amd64-i386-rhel6hvm-amd
> > test redhat-install
> >
> > Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> >
> > *** Found and reproduced problem changeset ***
>
> I had warned a number of times that a change like this should not be
> done: Afaict, this broke qemu-xen (and upstream qemu as well), which
> use BLKIF_MAX_SEGMENTS_PER_REQUEST without caring to set a
> specific __XEN_INTERFACE_VERSION__ (the tools generally just use
> 'latest').

Yes, we should have better foreseen this, especially given that you were
trying to tell us what we should see!

AFAICT the places which needed changing are:
* mini-os
* qemu-xen-traditional
* qemu-xen (upstream)

A patch (untested, but mostly done via sed) for mini-os follows. This
one really ought to have been forseen.

I was surprised that qemu (particularly upstream qemu) is building
against the Xen headers using __XEN_INTERFACE_VERSION__.

I think it is not worth fixing this for qemu-xen-traditional, so I will
follow up with the

> The same would go for tools/blktap*/.

That one never occurred to me, even after I grepped for the symbol.

> So either all uses within tools land get properly fixed (which is going to
> be particularly hard to synchronize with upstream qemu),

IMHO upstream qemu should either include it's own copy of the i/o
interface headers that it uses or it should use a specific
__XEN_INTERFACE_VERSION__. Is this something which is wrong with the
qemu tree or is it the Xen build system integration which is at fault?

I'll followup with a quick fix but IMHO it could be done better.

> or (my
> preference) the change gets reverted and done backward
> compatibly without involving __XEN_INTERFACE_VERSION__.

Given that it is blocking the test gate I think reverting it should be
strongly considered. As for how best to do this properly I have less of
an opinion.

That mini-os fix:

8<----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335066 0
# Node ID f351fec6d3960d537dde2cb35374982f6ea13e16
# Parent a4ef50b6313066d953314969494654f4f393558a
mini-os: Fix breakage causes by blkif.h interface change.

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting in mini-os.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/blkfront.c Mon Feb 27 09:31:06 2012 +0000
@@ -352,7 +352,7 @@ void blkfront_aio(struct blkfront_aiocb

/* qemu's IDE max multsect is 16 (8KB) and SCSI max DMA was set to 32KB,
* so max 44KB can't happen */
- ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_REQUEST);
+ ASSERT(n <= BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);

blkfront_wait_slot(dev);
i = dev->ring.req_prod_pvt;
diff -r a4ef50b63130 -r f351fec6d396 extras/mini-os/include/blkfront.h
--- a/extras/mini-os/include/blkfront.h Sat Feb 25 09:36:19 2012 +0000
+++ b/extras/mini-os/include/blkfront.h Mon Feb 27 09:31:06 2012 +0000
@@ -12,7 +12,7 @@ struct blkfront_aiocb
uint8_t is_write;
void *data;

- grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ grant_ref_t gref[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
int n;

void (*aio_cb)(struct blkfront_aiocb *aiocb, int ret);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
Ian.Campbell at citrix
Feb 27, 2012, 1:43 AM
Post #4 of 7 (146 views)
Permalink
On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
> > The same would go for tools/blktap*/.
>
> That one never occurred to me, even after I grepped for the symbol.

I guess the following ought to fix it...

8<---------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1330335804 0
# Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
# Parent 0bb45a06c1a8b049dba322cfb91c86c253068f0e
blktap: Fix after blkif.h update

24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here Fix after blkif.h update

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
--- a/tools/blktap/lib/blktaplib.h Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap/lib/blktaplib.h Mon Feb 27 09:43:24 2012 +0000
@@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *

/* Accessing attached data page mappings */
#define MMAP_PAGES \
- (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+ (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
#define MMAP_VADDR(_vstart,_req,_seg) \
((_vstart) + \
- ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) + \
+ ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) + \
((_seg) * getpagesize()))


diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
--- a/tools/blktap2/drivers/tapdisk-diff.c Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-diff.c Mon Feb 27 09:43:24 2012 +0000
@@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
breq->sector_number = sreq->sec;
breq->operation = BLKIF_OP_READ;

- for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+ for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
uint32_t secs;
struct blkif_request_segment *seg = breq->seg + i;

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
--- a/tools/blktap2/drivers/tapdisk-stream.c Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/drivers/tapdisk-stream.c Mon Feb 27 09:43:24 2012 +0000
@@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
breq->sector_number = sreq->sec;
breq->operation = BLKIF_OP_READ;

- for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
+ for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
struct blkif_request_segment *seg = breq->seg + i;

diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
--- a/tools/blktap2/include/blktaplib.h Mon Feb 27 09:37:45 2012 +0000
+++ b/tools/blktap2/include/blktaplib.h Mon Feb 27 09:43:24 2012 +0000
@@ -222,10 +222,10 @@ typedef struct msg_lock {

/* Accessing attached data page mappings */
#define MMAP_PAGES \
- (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
+ (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
#define MMAP_VADDR(_vstart,_req,_seg) \
((_vstart) + \
- ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) + \
+ ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) + \
((_seg) * getpagesize()))

/* Defines that are only used by library clients */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
JBeulich at suse
Feb 27, 2012, 2:00 AM
Post #5 of 7 (145 views)
Permalink
>>> On 27.02.12 at 10:32, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-02-27 at 09:03 +0000, Jan Beulich wrote:
>> or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
>
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

It's not only the blocking of the test gate: The kind of (unforeseen)
fallout we're having in our own tree should make us ask ourselves
again whether risking to break other people's code (who may have
just followed what we're doing) is worth it. This includes the (bogus
imo, as pointed out before) tying of io/* definitions to particular
__XEN_INTERFACE_VERSION__ values - each I/O interface should
be completely standalone.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
keir.xen at gmail
Feb 27, 2012, 4:11 AM
Post #6 of 7 (141 views)
Permalink
On 27/02/2012 09:32, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> or (my
>> preference) the change gets reverted and done backward
>> compatibly without involving __XEN_INTERFACE_VERSION__.
>
> Given that it is blocking the test gate I think reverting it should be
> strongly considered. As for how best to do this properly I have less of
> an opinion.

I reverted it for now at least. Perhaps it makes sense to do this with a new
macro name, as Jan suggested.

-- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd [ In reply to ]
justing at spectralogic
Feb 27, 2012, 7:22 AM
Post #7 of 7 (141 views)
Permalink
I think there is more to cleanup here. These drivers have their
own constant, MAX_SEGMENTS_PER_REQ. If this is the real driver
limit, it should be used consistently everywhere, but also tied to
blkif.h via a MIN() instead of directly hardcoded to 11.

I'm working on patches for this and the other isues within the
xen-unstable tree now, and will submit them for review once I
think they are ready.

--
Justin

On Feb 27, 2012, at 2:43 AM, Ian Campbell wrote:

> On Mon, 2012-02-27 at 09:32 +0000, Ian Campbell wrote:
>>> The same would go for tools/blktap*/.
>>
>> That one never occurred to me, even after I grepped for the symbol.
>
> I guess the following ought to fix it...
>
> 8<---------------------------------------------------
>
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1330335804 0
> # Node ID 42978617757ff3c8fce5c6d1873ad86d46c594ae
> # Parent 0bb45a06c1a8b049dba322cfb91c86c253068f0e
> blktap: Fix after blkif.h update
>
> 24875:a59c1dcfe968 made an incompatible change to the interface headers which
> needs to be reflected here Fix after blkif.h update
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap/lib/blktaplib.h
> --- a/tools/blktap/lib/blktaplib.h Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap/lib/blktaplib.h Mon Feb 27 09:43:24 2012 +0000
> @@ -230,10 +230,10 @@ int setup_probe_watch(struct xs_handle *
>
> /* Accessing attached data page mappings */
> #define MMAP_PAGES \
> - (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> + (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg) \
> ((_vstart) + \
> - ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) + \
> + ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) + \
> ((_seg) * getpagesize()))
>
>
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-diff.c
> --- a/tools/blktap2/drivers/tapdisk-diff.c Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-diff.c Mon Feb 27 09:43:24 2012 +0000
> @@ -429,7 +429,7 @@ tapdisk_stream_enqueue1(void)
> breq->sector_number = sreq->sec;
> breq->operation = BLKIF_OP_READ;
>
> - for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> + for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> uint32_t secs;
> struct blkif_request_segment *seg = breq->seg + i;
>
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/drivers/tapdisk-stream.c
> --- a/tools/blktap2/drivers/tapdisk-stream.c Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/drivers/tapdisk-stream.c Mon Feb 27 09:43:24 2012 +0000
> @@ -296,7 +296,7 @@ tapdisk_stream_enqueue(event_id_t id, ch
> breq->sector_number = sreq->sec;
> breq->operation = BLKIF_OP_READ;
> kk
> - for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_REQUEST; i++) {
> + for (i = 0; i < BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; i++) {
> uint32_t secs = MIN(s->end - s->cur, psize >> SECTOR_SHIFT);
> struct blkif_request_segment *seg = breq->seg + i;
>
> diff -r 0bb45a06c1a8 -r 42978617757f tools/blktap2/include/blktaplib.h
> --- a/tools/blktap2/include/blktaplib.h Mon Feb 27 09:37:45 2012 +0000
> +++ b/tools/blktap2/include/blktaplib.h Mon Feb 27 09:43:24 2012 +0000
> @@ -222,10 +222,10 @@ typedef struct msg_lock {
>
> /* Accessing attached data page mappings */
> #define MMAP_PAGES \
> - (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_REQUEST)
> + (MAX_PENDING_REQS * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK)
> #define MMAP_VADDR(_vstart,_req,_seg) \
> ((_vstart) + \
> - ((_req) * BLKIF_MAX_SEGMENTS_PER_REQUEST * getpagesize()) + \
> + ((_req) * BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * getpagesize()) + \
> ((_seg) * getpagesize()))
>
> /* Defines that are only used by library clients */
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal