From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [ovmf bisection] complete build-amd64
Date: Fri, 09 Jun 2017 21:10:09 +0000 [thread overview]
Message-ID: <E1dJRAX-0005gI-LR@osstest.test-lab.xenproject.org> (raw)
branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build
Tree: ovmf https://github.com/tianocore/edk2.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: ovmf https://github.com/tianocore/edk2.git
Bug introduced: 4275f38507a4a44260555495dfb6da1d8a307307
Bug not present: b941c34ef859971e29683ffb57c309e24e6a96be
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110214/
commit 4275f38507a4a44260555495dfb6da1d8a307307
Author: Laszlo Ersek <lersek@redhat.com>
Date: Sat Jun 3 16:11:08 2017 +0200
OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
... by narrower than 8-byte ADD_POINTER references.
Introduce the CollectAllocationsRestrictedTo32Bit() function, which
iterates over the linker/loader script, and collects the names of the
fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
means that the pointee blob's address will have to be patched into a
narrower-than-8 byte pointer field, hence the pointee blob must not be
allocated from 64-bit address space.
In ProcessCmdAllocate(), consult these restrictions when setting the
maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
unless restricted like described above to the pre-patch MAX_UINT32 limit.
In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
64-bit addressable ACPI objects", 2017-04-10), this patch enables
OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.
(An upcoming / planned aarch64 QEMU machine type will have no RAM under
4GB at all. Plus, moving the allocations higher is beneficial to the
current "virt" machine type as well; in Ard's words: "having all firmware
allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
the TLB footprint".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For bisection revision-tuple graph see:
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Running cs-bisection-step --graph-out=/home/logs/results/bisect/ovmf/build-amd64.xen-build --summary-out=tmp/110214.bisection-summary --basis-template=110078 --blessings=real,real-bisect ovmf build-amd64 xen-build
Searching for failure / basis pass:
110166 fail [host=huxelrebe0] / 110078 ok.
Failure / basis pass flights: 110166 / 110078
(tree with no url: minios)
(tree with no url: seabios)
Tree: ovmf https://github.com/tianocore/edk2.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 c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
Basis pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 d8eed4021d50eb48ca75c8559aed95a2ad74afaa
Generating revisions with ./adhoc-revtuple-generator https://github.com/tianocore/edk2.git#b941c34ef859971e29683ffb57c309e24e6a96be-c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 git://xenbits.xen.org/xen.git#d8eed4021d50eb48ca75c8559aed95a2ad74afaa-3d2010f9ffeacc8836811420460e15f2c1233695
Loaded 2001 nodes in revision graph
Searching for test results:
110078 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 d8eed4021d50eb48ca75c8559aed95a2ad74afaa
110104 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110117 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110139 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110199 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110173 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 d8eed4021d50eb48ca75c8559aed95a2ad74afaa
110214 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110206 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110192 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110193 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 8fd8951eabc6648fc302585187d02d49157ff907
110207 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110166 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110194 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 9c4f1b72571b215e80abf0490073438831dc785b
110196 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110197 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3127e85ba934a2be8c16b3277af88ccce948946a
110208 fail 4275f38507a4a44260555495dfb6da1d8a307307 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
110213 pass b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
Searching for interesting versions
Result found: flight 110078 (pass), for basis pass
Result found: flight 110166 (fail), for basis failure
Repro found: flight 110173 (pass), for basis pass
Repro found: flight 110196 (fail), for basis failure
0 revisions at b941c34ef859971e29683ffb57c309e24e6a96be 8051789e982499050680a26febeada7467e18a8d e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 3d2010f9ffeacc8836811420460e15f2c1233695
No revisions left to test, checking graph state.
Result found: flight 110199 (pass), for last pass
Result found: flight 110206 (fail), for first failure
Repro found: flight 110207 (pass), for last pass
Repro found: flight 110208 (fail), for first failure
Repro found: flight 110213 (pass), for last pass
Repro found: flight 110214 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: ovmf https://github.com/tianocore/edk2.git
Bug introduced: 4275f38507a4a44260555495dfb6da1d8a307307
Bug not present: b941c34ef859971e29683ffb57c309e24e6a96be
Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110214/
commit 4275f38507a4a44260555495dfb6da1d8a307307
Author: Laszlo Ersek <lersek@redhat.com>
Date: Sat Jun 3 16:11:08 2017 +0200
OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
... by narrower than 8-byte ADD_POINTER references.
Introduce the CollectAllocationsRestrictedTo32Bit() function, which
iterates over the linker/loader script, and collects the names of the
fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
means that the pointee blob's address will have to be patched into a
narrower-than-8 byte pointer field, hence the pointee blob must not be
allocated from 64-bit address space.
In ProcessCmdAllocate(), consult these restrictions when setting the
maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
unless restricted like described above to the pre-patch MAX_UINT32 limit.
In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
64-bit addressable ACPI objects", 2017-04-10), this patch enables
OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.
(An upcoming / planned aarch64 QEMU machine type will have no RAM under
4GB at all. Plus, moving the allocations higher is beneficial to the
current "virt" machine type as well; in Ard's words: "having all firmware
allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
the TLB footprint".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Revision graph left in /home/logs/results/bisect/ovmf/build-amd64.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
110214: tolerable ALL FAIL
flight 110214 ovmf real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/110214/
Failures :-/ but no regressions.
Tests which did not succeed,
including tests which could not be run:
build-amd64 5 xen-build fail baseline untested
jobs:
build-amd64 fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next reply other threads:[~2017-06-09 21:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-09 21:10 osstest service owner [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-05-01 16:26 [ovmf bisection] complete build-amd64 osstest service owner
2022-03-01 11:04 osstest service owner
2021-12-09 13:25 osstest service owner
2021-09-01 14:34 osstest service owner
2019-01-09 4:07 osstest service owner
2018-11-08 3:37 osstest service owner
2018-07-19 5:12 osstest service owner
2018-04-07 10:57 osstest service owner
2017-09-10 21:15 osstest service owner
2017-09-06 14:37 osstest service owner
2017-07-05 22:10 osstest service owner
2016-06-30 7:00 osstest service owner
2015-06-13 13:13 osstest service user
2015-05-21 6:59 osstest service user
2015-05-21 8:54 ` Ian Campbell
2015-01-31 14:29 xen.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1dJRAX-0005gI-LR@osstest.test-lab.xenproject.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).