[Xen-devel] [ovmf bisection] complete build-i386

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

branch xen-unstable
xenbranch xen-unstable
job build-i386
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/110256/


  commit 4275f38507a4a44260555495dfb6da1d8a307307
  Author: Laszlo Ersek <lersek@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
      Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
      Suggested-by: Igor Mammedov <imammedo@xxxxxxxxxx>
      Suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
      Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-i386.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-i386.xen-build 
--summary-out=tmp/110256.bisection-summary --basis-template=110078 
--blessings=real,real-bisect ovmf build-i386 xen-build
Searching for failure / basis pass:
 110166 fail [host=italia0] / 110078 [host=nobling0] 110056 [host=elbling0] 
110023 [host=chardonnay0] 110011 [host=nobling1] 110007 [host=italia1] 109950 
[host=nocera0] 109932 [host=baroque0] 109931 [host=nobling0] 109930 
[host=italia1] 109923 [host=rimava1] 109915 [host=baroque0] 109877 
[host=baroque1] 109835 [host=elbling0] 109816 [host=elbling1] 109794 
[host=baroque0] 109791 [host=italia1] 109761 [host=elbling0] 109737 
[host=italia1] 109731 [host=chardonnay0] 109727 [host=elbling1] 109720 
[host=huxelrebe0] 109714 [host=elbling1] 109700 [host=huxelrebe0] 109695 
[host=rimava1] 109691 ok.
Failure / basis pass flights: 110166 / 109691
(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 ac63e9392e7aa3791a4ea00e43c0658e6b20e2ee 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3fafdc28eb98dc1cb686379d83270516fc38049d
Generating revisions with ./adhoc-revtuple-generator  
https://github.com/tianocore/edk2.git#ac63e9392e7aa3791a4ea00e43c0658e6b20e2ee-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#3fafdc28eb98dc1cb686379d83270516fc38049d-3d2010f9ffeacc8836811420460e15f2c1233695
Loaded 2001 nodes in revision graph
Searching for test results:
 109714 [host=elbling1]
 109700 [host=huxelrebe0]
 109691 pass ac63e9392e7aa3791a4ea00e43c0658e6b20e2ee 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3fafdc28eb98dc1cb686379d83270516fc38049d
 109695 [host=rimava1]
 109731 [host=chardonnay0]
 109720 [host=huxelrebe0]
 109737 [host=italia1]
 109727 [host=elbling1]
 109761 [host=elbling0]
 109835 [host=elbling0]
 109791 [host=italia1]
 109816 [host=elbling1]
 109794 [host=baroque0]
 109877 [host=baroque1]
 109915 [host=baroque0]
 109923 [host=rimava1]
 109930 [host=italia1]
 109931 [host=nobling0]
 109932 [host=baroque0]
 109950 [host=nocera0]
 110007 [host=italia1]
 110011 [host=nobling1]
 110078 [host=nobling0]
 110023 [host=chardonnay0]
 110056 [host=elbling0]
 110104 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110117 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110229 pass 9c94cc2ca270c2a9121c485281792c178281ac7d 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110139 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110215 pass ac63e9392e7aa3791a4ea00e43c0658e6b20e2ee 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3fafdc28eb98dc1cb686379d83270516fc38049d
 110235 pass d4c558e83d8f428393d27816772efc7f4b0e8403 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110166 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110226 pass 7b5d848dbfc3abe8b8c6066168bf10eca39d5891 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3127e85ba934a2be8c16b3277af88ccce948946a
 110223 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110238 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110224 pass 4fc8277133fb011d028b4e0a42444ab6f552d0b9 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
b02728b3b689e145a52c46cd9eae5be48e905df7
 110225 pass a04ec6d9f70f7eedf5ab49b098970245270fa594 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
d8eed4021d50eb48ca75c8559aed95a2ad74afaa
 110233 pass b9f1625193a6e83aed59c5b801f105b8ba8cc546 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110241 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110246 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110248 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110255 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110256 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
Searching for interesting versions
 Result found: flight 109691 (pass), for basis pass
 Result found: flight 110166 (fail), for basis failure
 Repro found: flight 110215 (pass), for basis pass
 Repro found: flight 110223 (fail), for basis failure
 0 revisions at b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
No revisions left to test, checking graph state.
 Result found: flight 110238 (pass), for last pass
 Result found: flight 110241 (fail), for first failure
 Repro found: flight 110246 (pass), for last pass
 Repro found: flight 110248 (fail), for first failure
 Repro found: flight 110255 (pass), for last pass
 Repro found: flight 110256 (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/110256/


  commit 4275f38507a4a44260555495dfb6da1d8a307307
  Author: Laszlo Ersek <lersek@xxxxxxxxxx>
  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@xxxxxxxxxx>
      Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
      Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
      Suggested-by: Igor Mammedov <imammedo@xxxxxxxxxx>
      Suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
      Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

Revision graph left in 
/home/logs/results/bisect/ovmf/build-i386.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
110256: tolerable ALL FAIL

flight 110256 ovmf real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/110256/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386                    5 xen-build               fail baseline untested


jobs:
 build-i386                                                   fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


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