* [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
@ 2012-02-25 0:56 xen.org
2012-02-27 9:03 ` Jan Beulich
0 siblings, 1 reply; 11+ messages in thread
From: xen.org @ 2012-02-25 0:56 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-25 0:56 [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd xen.org
@ 2012-02-27 9:03 ` Jan Beulich
2012-02-27 9:32 ` Ian Campbell
0 siblings, 1 reply; 11+ messages in thread
From: Jan Beulich @ 2012-02-27 9:03 UTC (permalink / raw)
To: Justin T. Gibbs, keir; +Cc: xen-devel, ian.jackson, stefano.stabellini
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-27 9:03 ` Jan Beulich
@ 2012-02-27 9:32 ` Ian Campbell
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Ian Campbell @ 2012-02-27 9:32 UTC (permalink / raw)
To: Jan Beulich
Cc: Justin T. Gibbs, xen-devel, Keir (Xen.org),
Ian Jackson, Stefano Stabellini
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);
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH qemu-xen-traditional] Fix after blkif.h update
2012-02-27 9:32 ` Ian Campbell
@ 2012-02-27 9:34 ` Ian Campbell
2012-02-27 9:36 ` [PATCH qemu-xen] " Ian Campbell
2012-02-27 9:52 ` [PATCH qemu-xen-traditional] " Jan Beulich
2012-02-27 9:43 ` [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd Ian Campbell
` (2 subsequent siblings)
3 siblings, 2 replies; 11+ messages in thread
From: Ian Campbell @ 2012-02-27 9:34 UTC (permalink / raw)
To: Jan Beulich
Cc: Justin T. Gibbs, xen-devel, Keir (Xen.org),
Ian Jackson, Stefano Stabellini
24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs to be reflected here.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
block-vbd.c | 2 +-
hw/e1000.c | 3 +++
hw/ide.c | 2 +-
hw/scsi-disk.c | 2 +-
hw/xen_blkif.h | 8 ++++----
hw/xen_disk.c | 12 ++++++------
6 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/block-vbd.c b/block-vbd.c
index 71f1731..2a80f09 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -33,7 +33,7 @@
#include <xen/io/blkif.h>
#define IDE_DMA_BUF_SECTORS \
- (((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+ (((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
#define IDE_DMA_BUF_BYTES (IDE_DMA_BUF_SECTORS * 512)
#define SECTOR_SIZE 512
diff --git a/hw/e1000.c b/hw/e1000.c
index bb3689e..97104ed 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
bytes = split_size;
if (tp->size + bytes > msh)
bytes = msh - tp->size;
+
+ bytes = MIN(sizeof(tp->data) - tp->size, bytes);
cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
memmove(tp->header, tp->data, hdr);
@@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
// context descriptor TSE is not set, while data descriptor TSE is set
DBGOUT(TXERR, "TCP segmentaion Error\n");
} else {
+ split_size = MIN(sizeof(tp->data) - tp->size, split_size);
cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
tp->size += split_size;
}
diff --git a/hw/ide.c b/hw/ide.c
index 791666b..c3d3d60 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -209,7 +209,7 @@
#ifdef CONFIG_STUBDOM
#include <xen/io/blkif.h>
#define IDE_DMA_BUF_SECTORS \
- (((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1 ) * TARGET_PAGE_SIZE) / 512)
+ (((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1 ) * TARGET_PAGE_SIZE) / 512)
#else
#define IDE_DMA_BUF_SECTORS 256
#endif
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 520009e..99c2cdf 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -42,7 +42,7 @@ do { fprintf(stderr, "scsi-disk: " fmt , ##args); } while (0)
#ifdef CONFIG_STUBDOM
#include <xen/io/blkif.h>
-#define SCSI_DMA_BUF_SIZE ((BLKIF_MAX_SEGMENTS_PER_REQUEST - 1) * TARGET_PAGE_SIZE)
+#define SCSI_DMA_BUF_SIZE ((BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK - 1) * TARGET_PAGE_SIZE)
#else
#define SCSI_DMA_BUF_SIZE 131072
#endif
diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index ca3a65b..485a166 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -24,7 +24,7 @@ struct blkif_x86_32_request {
blkif_vdev_t handle; /* only for read/write requests */
uint64_t id; /* private guest value, echoed in resp */
blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
- struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
};
struct blkif_x86_32_response {
uint64_t id; /* copied from request */
@@ -42,7 +42,7 @@ struct blkif_x86_64_request {
blkif_vdev_t handle; /* only for read/write requests */
uint64_t __attribute__((__aligned__(8))) id;
blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
- struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
};
struct blkif_x86_64_response {
uint64_t __attribute__((__aligned__(8))) id;
@@ -72,7 +72,7 @@ enum blkif_protocol {
static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
{
- int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+ int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
dst->operation = src->operation;
dst->nr_segments = src->nr_segments;
@@ -87,7 +87,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
{
- int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+ int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
dst->operation = src->operation;
dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 6aebb77..092def8 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -55,7 +55,7 @@ static int use_aio = 0;
/* ------------------------------------------------------------- */
#define BLOCK_SIZE 512
-#define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
struct ioreq {
blkif_request_t req;
@@ -68,10 +68,10 @@ struct ioreq {
int postsync;
/* grant mapping */
- uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
- uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ uint32_t domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+ uint32_t refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
int prot;
- void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ void *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
void *pages;
/* aio status */
@@ -127,7 +127,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
ioreq = qemu_mallocz(sizeof(*ioreq));
ioreq->blkdev = blkdev;
blkdev->requests_total++;
- qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+ qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
} else {
/* get one from freelist */
ioreq = LIST_FIRST(&blkdev->freelist);
@@ -207,7 +207,7 @@ static int ioreq_parse(struct ioreq *ioreq)
ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
for (i = 0; i < ioreq->req.nr_segments; i++) {
- if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+ if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
goto err;
}
--
1.7.2.5
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH qemu-xen] Fix after blkif.h update
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
@ 2012-02-27 9:36 ` Ian Campbell
2012-02-27 9:52 ` [PATCH qemu-xen-traditional] " Jan Beulich
1 sibling, 0 replies; 11+ messages in thread
From: Ian Campbell @ 2012-02-27 9:36 UTC (permalink / raw)
To: Jan Beulich
Cc: xen-devel, Keir (Xen.org),
Stefano Stabellini, Ian Jackson, Justin T. Gibbs, Anthony Perard
24875:a59c1dcfe968 made an incompatible change to the interface headers which
needs reflecting here. A compatibility definition is included in order to keep
building with older versions of the headers.
IMHO qemu should contain a copy of the interface headers of its own so that it
can update at its own pace (like most guest OSes do).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
hw/xen_blkif.h | 13 +++++++++----
hw/xen_disk.c | 12 ++++++------
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/hw/xen_blkif.h b/hw/xen_blkif.h
index c0f4136..5db8319 100644
--- a/hw/xen_blkif.h
+++ b/hw/xen_blkif.h
@@ -5,6 +5,11 @@
#include <xen/io/blkif.h>
#include <xen/io/protocols.h>
+/* Compatibility with older blkif headers */
+#ifndef BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK
+#define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK BLKIF_MAX_SEGMENTS_PER_REQUEST
+#endif
+
/* Not a real protocol. Used to generate ring structs which contain
* the elements common to all protocols only. This way we get a
* compiler-checkable way to use common struct elements, so we can
@@ -24,7 +29,7 @@ struct blkif_x86_32_request {
blkif_vdev_t handle; /* only for read/write requests */
uint64_t id; /* private guest value, echoed in resp */
blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
- struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
};
struct blkif_x86_32_response {
uint64_t id; /* copied from request */
@@ -42,7 +47,7 @@ struct blkif_x86_64_request {
blkif_vdev_t handle; /* only for read/write requests */
uint64_t __attribute__((__aligned__(8))) id;
blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
- struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
};
struct blkif_x86_64_response {
uint64_t __attribute__((__aligned__(8))) id;
@@ -72,7 +77,7 @@ enum blkif_protocol {
static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_request_t *src)
{
- int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+ int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
dst->operation = src->operation;
dst->nr_segments = src->nr_segments;
@@ -87,7 +92,7 @@ static inline void blkif_get_x86_32_req(blkif_request_t *dst, blkif_x86_32_reque
static inline void blkif_get_x86_64_req(blkif_request_t *dst, blkif_x86_64_request_t *src)
{
- int i, n = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+ int i, n = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK;
dst->operation = src->operation;
dst->nr_segments = src->nr_segments;
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 286bbac..0f22bc6 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -54,7 +54,7 @@ static int use_aio = 1;
/* ------------------------------------------------------------- */
#define BLOCK_SIZE 512
-#define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_REQUEST + 2)
+#define IOCB_COUNT (BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + 2)
struct ioreq {
blkif_request_t req;
@@ -67,10 +67,10 @@ struct ioreq {
int postsync;
/* grant mapping */
- uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
- uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ uint32_t domids[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
+ uint32_t refs[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
int prot;
- void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+ void *page[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK];
void *pages;
/* aio status */
@@ -128,7 +128,7 @@ static struct ioreq *ioreq_start(struct XenBlkDev *blkdev)
ioreq = g_malloc0(sizeof(*ioreq));
ioreq->blkdev = blkdev;
blkdev->requests_total++;
- qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_REQUEST);
+ qemu_iovec_init(&ioreq->v, BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK);
} else {
/* get one from freelist */
ioreq = QLIST_FIRST(&blkdev->freelist);
@@ -210,7 +210,7 @@ static int ioreq_parse(struct ioreq *ioreq)
ioreq->start = ioreq->req.sector_number * blkdev->file_blk;
for (i = 0; i < ioreq->req.nr_segments; i++) {
- if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) {
+ if (i == BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) {
xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n");
goto err;
}
--
1.7.2.5
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-27 9:32 ` Ian Campbell
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
@ 2012-02-27 9:43 ` Ian Campbell
2012-02-27 15:22 ` Justin T. Gibbs
2012-02-27 10:00 ` Jan Beulich
2012-02-27 12:11 ` Keir Fraser
3 siblings, 1 reply; 11+ messages in thread
From: Ian Campbell @ 2012-02-27 9:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Justin T. Gibbs, xen-devel, Keir (Xen.org),
Ian Jackson, Stefano Stabellini
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 */
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH qemu-xen-traditional] Fix after blkif.h update
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
2012-02-27 9:36 ` [PATCH qemu-xen] " Ian Campbell
@ 2012-02-27 9:52 ` Jan Beulich
1 sibling, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2012-02-27 9:52 UTC (permalink / raw)
To: Ian Campbell
Cc: Justin T. Gibbs, Keir (Xen.org),
xen-devel, Ian Jackson, Stefano Stabellini
>>> On 27.02.12 at 10:34, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> diff --git a/hw/e1000.c b/hw/e1000.c
> index bb3689e..97104ed 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -444,6 +444,8 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
> bytes = split_size;
> if (tp->size + bytes > msh)
> bytes = msh - tp->size;
> +
> + bytes = MIN(sizeof(tp->data) - tp->size, bytes);
> cpu_physical_memory_read(addr, tp->data + tp->size, bytes);
> if ((sz = tp->size + bytes) >= hdr && tp->size < hdr)
> memmove(tp->header, tp->data, hdr);
> @@ -459,6 +461,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
> // context descriptor TSE is not set, while data descriptor TSE is set
> DBGOUT(TXERR, "TCP segmentaion Error\n");
> } else {
> + split_size = MIN(sizeof(tp->data) - tp->size, split_size);
> cpu_physical_memory_read(addr, tp->data + tp->size, split_size);
> tp->size += split_size;
> }
What are these two changes doing here?
Jan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-27 9:32 ` Ian Campbell
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
2012-02-27 9:43 ` [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd Ian Campbell
@ 2012-02-27 10:00 ` Jan Beulich
2012-02-27 12:11 ` Keir Fraser
3 siblings, 0 replies; 11+ messages in thread
From: Jan Beulich @ 2012-02-27 10:00 UTC (permalink / raw)
To: Ian Campbell
Cc: Justin T. Gibbs, Keir (Xen.org),
xen-devel, Ian Jackson, Stefano Stabellini
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-27 9:32 ` Ian Campbell
` (2 preceding siblings ...)
2012-02-27 10:00 ` Jan Beulich
@ 2012-02-27 12:11 ` Keir Fraser
3 siblings, 0 replies; 11+ messages in thread
From: Keir Fraser @ 2012-02-27 12:11 UTC (permalink / raw)
To: Ian Campbell, Jan Beulich
Cc: Justin T. Gibbs, xen-devel, Keir (Xen.org),
Ian Jackson, Stefano Stabellini
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
2012-02-27 9:43 ` [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd Ian Campbell
@ 2012-02-27 15:22 ` Justin T. Gibbs
0 siblings, 0 replies; 11+ messages in thread
From: Justin T. Gibbs @ 2012-02-27 15:22 UTC (permalink / raw)
To: Ian Campbell
Cc: Ian Jackson, xen-devel, Keir (Xen.org), Jan Beulich, Stefano Stabellini
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 */
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd
@ 2012-10-18 6:12 xen.org
0 siblings, 0 replies; 11+ messages in thread
From: xen.org @ 2012-10-18 6:12 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-rhel6hvm-amd
test xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.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/hg/staging/xen-unstable.hg
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Bug introduced: 4fc87c2f31a0
Bug not present: c1c549c4fe9e
changeset: 26060:4fc87c2f31a0
user: Huang Ying <ying.huang@intel.com>
date: Tue Oct 16 17:26:36 2012 +0200
ACPI: fix APEI related table size checking
On Huang Ying's machine:
erst_tab->header_length == sizeof(struct acpi_table_einj)
but Yinghai reported that on his machine,
erst_tab->header_length == sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)
To make erst table size checking code works on all systems, both
testing are treated as PASS.
Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.
Originally-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Huang Ying <ying.huang@intel.com>
- use switch() for better readability
- add comment explaining why a formally invalid size it also being
accepted
- check erst_tab->header.length before even looking at
erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Searching for failure / basis pass:
14017 fail [host=moss-bug] / 13967 [host=lace-bug] 13963 [host=potato-beetle] 13962 ok.
Failure / basis pass flights: 14017 / 13962
Tree: linux git://xenbits.xen.org/linux-pvops.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/hg/staging/xen-unstable.hg
Latest a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
Basis pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#a938a246d34912423c560f475ccf1ce0c71d9d00-a938a246d34912423c560f475ccf1ce0c71d9d00 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bacc0d302445c75f18f4c826750fb5853b60e7ca-bacc0d302445c75f18f4c826750fb5853b60e7ca git://xenbits.xen.org/staging/qemu-upstream-unstable.git#cdf4d2bb4006805f209712fbb8ed1f83127e9984-cdf4d2bb4006805f209712fbb8ed1f83127e9984 http://xenbits.xen.org/hg/staging/xen-unstable.hg#e0e1350dfe9b-5c402b905e00
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 252 nodes in revision graph
Searching for test results:
13958 [host=lace-bug]
13960 [host=leaf-beetle]
13967 [host=lace-bug]
13962 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
13972 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
13963 [host=potato-beetle]
13956 [host=potato-beetle]
13964 []
13973 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
13979 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
13997 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
14000 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
13996 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
13998 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 177fdda0be56
13995 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4b4c0c7a6031
13999 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 37bb894121c7
14001 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 1f4be6ee4619
14007 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
14011 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
14018 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 e0e1350dfe9b
14019 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
14020 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
14017 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 5c402b905e00
14021 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
14022 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
14023 pass a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
14024 fail a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 4fc87c2f31a0
Searching for interesting versions
Result found: flight 13962 (pass), for basis pass
Result found: flight 14007 (fail), for basis failure
Repro found: flight 14018 (pass), for basis pass
Repro found: flight 14019 (fail), for basis failure
0 revisions at a938a246d34912423c560f475ccf1ce0c71d9d00 bacc0d302445c75f18f4c826750fb5853b60e7ca cdf4d2bb4006805f209712fbb8ed1f83127e9984 c1c549c4fe9e
No revisions left to test, checking graph state.
Result found: flight 14000 (pass), for last pass
Result found: flight 14020 (fail), for first failure
Repro found: flight 14021 (pass), for last pass
Repro found: flight 14022 (fail), for first failure
Repro found: flight 14023 (pass), for last pass
Repro found: flight 14024 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/hg/staging/xen-unstable.hg
Bug introduced: 4fc87c2f31a0
Bug not present: c1c549c4fe9e
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
changeset: 26060:4fc87c2f31a0
user: Huang Ying <ying.huang@intel.com>
date: Tue Oct 16 17:26:36 2012 +0200
ACPI: fix APEI related table size checking
On Huang Ying's machine:
erst_tab->header_length == sizeof(struct acpi_table_einj)
but Yinghai reported that on his machine,
erst_tab->header_length == sizeof(struct acpi_table_einj) -
sizeof(struct acpi_table_header)
To make erst table size checking code works on all systems, both
testing are treated as PASS.
Same situation applies to einj_tab->header_length, so corresponding
table size checking is changed in similar way too.
Originally-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Huang Ying <ying.huang@intel.com>
- use switch() for better readability
- add comment explaining why a formally invalid size it also being
accepted
- check erst_tab->header.length before even looking at
erst_tab->header_length
- prefer sizeof(*erst_tab) over sizeof(struct acpi_table_erst)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-amd.xen-boot.{dot,ps,png,html}.
----------------------------------------
14024: tolerable ALL FAIL
flight 14024 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/14024/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
test-amd64-i386-rhel6hvm-amd 5 xen-boot fail baseline untested
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-10-18 6:12 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-25 0:56 [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd xen.org
2012-02-27 9:03 ` Jan Beulich
2012-02-27 9:32 ` Ian Campbell
2012-02-27 9:34 ` [PATCH qemu-xen-traditional] Fix after blkif.h update Ian Campbell
2012-02-27 9:36 ` [PATCH qemu-xen] " Ian Campbell
2012-02-27 9:52 ` [PATCH qemu-xen-traditional] " Jan Beulich
2012-02-27 9:43 ` [xen-unstable bisection] complete test-amd64-i386-rhel6hvm-amd Ian Campbell
2012-02-27 15:22 ` Justin T. Gibbs
2012-02-27 10:00 ` Jan Beulich
2012-02-27 12:11 ` Keir Fraser
2012-10-18 6:12 xen.org
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.