From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org
Subject: [ovmf test] 94773: regressions - FAIL
Date: Thu, 26 May 2016 02:53:47 +0000 [thread overview]
Message-ID: <osstest-94773-mainreport@xen.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 13761 bytes --]
flight 94773 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748
version targeted for testing:
ovmf 855743f7177459bea95798e59b6b18dab867710c
baseline version:
ovmf dc99315b8732b6e3032d01319d3f534d440b43d0
Last test of basis 94748 2016-05-24 22:43:25 Z 1 days
Failing since 94750 2016-05-25 03:43:08 Z 0 days 4 attempts
Testing same since 94773 2016-05-25 19:44:42 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Dandan Bi <dandan.bi@intel.com>
Hao Wu <hao.a.wu@intel.com>
Laszlo Ersek <lersek@redhat.com>
Marvin H?user <Marvin.Haeuser@outlook.com>
Marvin Haeuser <Marvin.Haeuser@outlook.com>
Yonghong Zhu <yonghong.zhu@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-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
Not pushing.
------------------------------------------------------------
commit 855743f7177459bea95798e59b6b18dab867710c
Author: Laszlo Ersek <lersek@redhat.com>
Date: Wed May 18 20:13:41 2016 +0200
OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit d85c5e31ed2b550dd801f82e4ddb5f7583332098
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 19:30:24 2016 +0200
OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLib
This completes the transition to the new BDS.
The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit 2542feea2ecd4dc73ee54cb32c875839413eed05
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 19:22:17 2016 +0200
OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter list
With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no
longer need the BootOptionList parameter in the SetBootOrderFromQemu()
prototype. Update the library class header file (including the function's
documentation), and adapt the library instance and the call sites.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit 35d3e9c5222304b2015566955a6c427016368793
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 18:52:49 2016 +0200
OvmfPkg: remove QemuBootOrderLib instance
This library instance is no longer referenced.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit c70c9bc39d7cc9e409b77c736020a65a632571c8
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 18:51:48 2016 +0200
OvmfPkg: remove PlatformBdsLib instance
This library instance is no longer referenced.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit dd43486577b35ea53794fd443d391e3d04143412
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 18:32:24 2016 +0200
OvmfPkg: remove USE_OLD_BDS build fallback macro
Reasons:
- USE_OLD_BDS requires duplicating updates between OVMF's library
instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples:
d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI
spec Mantis 1353
1da761664949 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec
Mantis 1353
- The Xen community has embraced the new BDS. Examples:
14b2ebc30c8b OvmfPkg/PlatformBootManagerLib: Postpone the shell
registration
49effaf26ec9 OvmfPkg/PciHostBridgeLib: Scan for root bridges when
running over Xen
- OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as
NetworkPkg/HttpBootDxe now requires UefiBootManagerLib:
50a65824c74a NetworkPkg: Use UefiBootManagerLib API to create load
option.
We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is
TRUE.
- The new BDS has been working well; for example it's the only BDS
available in ArmVirtPkg:
1946faa710e6 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit a27e904258b9e848d91cdf22e7c20e2131249cfb
Author: Laszlo Ersek <lersek@redhat.com>
Date: Tue May 17 18:47:02 2016 +0200
OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in examples
The "UNIXGCC Debug" section happens to name PlatformBdsLib and
IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering
those even as a fallback option.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
commit 8caa3caaed4b32d699b79c6d5aaa606b52d740e7
Author: Dandan Bi <dandan.bi@intel.com>
Date: Mon May 23 14:54:46 2016 +0800
MdeModulePkg: Make function comments and function match in UI codes
Cc: Qiu Shumin <shumin.qiu@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
commit 4b7345a7dd71bdc99a824facf55066838ec240da
Author: Dandan Bi <dandan.bi@intel.com>
Date: Thu May 19 14:17:34 2016 +0800
MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine
The following codes are useless and cause memory leak issues.
So now remove them.
Cc: Cecil Sheng <cecil.sheng@hpe.com>
Cc: Qiu Shumin <shumin.qiu@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
commit e4979beee9e5d334d97fd8e2c79670ad08587bc6
Author: Yonghong Zhu <yonghong.zhu@intel.com>
Date: Fri May 6 15:20:23 2016 +0800
BaseTools/GenFds: enhance to get TOOL_CHAIN_TAG and TARGET value
when user don't set TOOL_CHAIN_TAG and TARGET by –D Flag, then GenFds
would report failure for format:
FILE DATA = $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/testfile
so this patch enhance to get the TOOL_CHAIN_TAG and TARGET value by
following priority (high to low): 1. the Macro value set by -D Flag;
2. Get the value by the -t/-b option. 3. get the value from target.txt
file. Besides, this patch also remove the error checking for missing
-t/-b option.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
commit 07fb9c264400d7ca2c14d3d8076102584038eb96
Author: Hao Wu <hao.a.wu@intel.com>
Date: Mon May 23 11:40:30 2016 +0800
MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
commit bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2
Author: Marvin H?user <Marvin.Haeuser@outlook.com>
Date: Fri May 20 03:04:02 2016 +0800
ShellPkg/App: Fix memory leak and save resources.
1) RunSplitCommand() allocates the initial SplitStdOut via
CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
the memory leak.
2) In RunSplitCommand(), SplitStdOut is checked for equality with
StdIn. This cannot happen due to the if-check within the swap.
Hence remove it.
3) UefiMain() doesn't free SplitList. Delete all list entries and
reinitialize the list when in DEBUG. This does not include the
CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so
keep the ASSERT() until resolved.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
reply other threads:[~2016-05-26 2:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=osstest-94773-mainreport@xen.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).