* [ovmf test] 58956: regressions - FAIL
@ 2015-06-28 22:32 osstest service user
2015-06-29 9:32 ` Ian Campbell
0 siblings, 1 reply; 5+ messages in thread
From: osstest service user @ 2015-06-28 22:32 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 58956 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58956/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58919
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58919
version targeted for testing:
ovmf 79d274b8b6b113248661c18f31c4be03c7da32de
baseline version:
ovmf 495ee9b85141dd9b65434d677b3a685fe166128d
------------------------------------------------------------
People who touched revisions under test:
Laszlo Ersek <lersek@redhat.com>
Maoming <maoming.maoming@huawei.com>
Wei Liu <wei.liu2@citrix.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-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
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
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 79d274b8b6b113248661c18f31c4be03c7da32de
Author: Laszlo Ersek <lersek@redhat.com>
Date: Fri Jun 26 16:09:52 2015 +0000
OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
At the moment we work with a UC default MTRR type, and set three memory
ranges to WB:
- [0, 640 KB),
- [1 MB, LowerMemorySize),
- [4 GB, 4 GB + UpperMemorySize).
Unfortunately, coverage for the third range can fail with a high
likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
the size (UpperMemorySize) differ, then MtrrLib creates a series of
variable MTRR entries, with power-of-two sized MTRR masks. And, it's
really easy to run out of variable MTRR entries, dependent on the
alignment difference.
This is a problem because a Linux guest will loudly reject any high memory
that is not covered my MTRR.
So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
- flip the MTRR default type to WB,
- set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
type and variable MTRRs, so we can't avoid this,
- set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
- set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
more likely than the other scheme (due to less chaotic alignment
differences).
Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000)
in PcdDebugPrintErrorLevel.
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17722 6f19259b-4bc3-4df7-8a09-765794883524
commit cfc80e2e95ee639e240c09eaeab76c0286bf917e
Author: Laszlo Ersek <lersek@redhat.com>
Date: Fri Jun 26 16:09:48 2015 +0000
OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
Build the memory HOBs in a tight block, in increasing base address order.
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17721 6f19259b-4bc3-4df7-8a09-765794883524
commit 86a14b0a7b89d5c301a167fa71ab765f56b878f0
Author: Laszlo Ersek <lersek@redhat.com>
Date: Fri Jun 26 16:09:43 2015 +0000
OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
Maoming reported that guest memory sizes equal to or larger than 64GB
were not correctly handled by OVMF.
Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and
starting QEMU with 64GB guest RAM size, I found the following error in the
OVMF debug log:
> GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000)
> GcdMemoryType = Reserved
> Capabilities = 030000000000000F
> Status = Unsupported
This message is emitted when the DXE core is initializing the memory space
map, processing the "above 4GB" memory resource descriptor HOB that was
created by OVMF's QemuInitializeRam() function (see "UpperMemorySize").
The DXE core's call chain fails in:
CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
CoreConvertSpace()
//
// Search for the list of descriptors that cover the range BaseAddress
// to BaseAddress+Length
//
CoreSearchGcdMapEntry()
CoreSearchGcdMapEntry() fails because the one entry (with type
"nonexistent") in the initial GCD memory space map is too small, and
cannot be split to cover the memory space range being added:
> GCD:Initial GCD Memory Space Map
> GCDMemType Range Capabilities Attributes
> ========== ================================= ================ ================
> NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000
The size of this initial entry is determined from the CPU HOB
(CoreInitializeGcdServices()).
Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth,
which is the narrowest valid value to cover the entire guest RAM.
Reported-by: Maoming <maoming.maoming@huawei.com>
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
commit bc89fe4879012b3d8e0b8f7a73bc0b2c122db5ad
Author: Laszlo Ersek <lersek@redhat.com>
Date: Fri Jun 26 16:09:39 2015 +0000
OvmfPkg: PlatformPei: enable larger permanent PEI RAM
We'll soon increase the maximum guest-physical RAM size supported by OVMF.
For more RAM, the DXE IPL is going to build more page tables, and for that
it's going to need a bigger chunk from the permanent PEI RAM.
Otherwise CreateIdentityMappingPageTables() would fail with:
> DXE IPL Entry
> Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi
> Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260
> AllocatePages failed: No 0x40201 Pages is available.
> There is only left 0x3F1F pages memory resource to be allocated.
> ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123):
> BigPageAddress != 0
(The above example belongs to the artificially high, maximal address width
of 52, clamped by the DXE core to 48. The address width of 48 bits
corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging
structures.)
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Brian J. Johnson <bjohnson@sgi.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brian J. Johnson <bjohnson@sgi.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ovmf test] 58956: regressions - FAIL
2015-06-28 22:32 [ovmf test] 58956: regressions - FAIL osstest service user
@ 2015-06-29 9:32 ` Ian Campbell
2015-06-30 16:53 ` Anthony PERARD
0 siblings, 1 reply; 5+ messages in thread
From: Ian Campbell @ 2015-06-29 9:32 UTC (permalink / raw)
To: xen-devel, ian.jackson; +Cc: Anthony Perard, Wei Liu
On Sun, 2015-06-28 at 22:32 +0000, osstest service user wrote:
> flight 58956 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/58956/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58919
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-win7-amd64.windows-install.html smells like something in the range:
$ git log --oneline 495ee9b85..79d274b8b
79d274b OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
cfc80e2 OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
86a14b0 OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
bc89fe4 OvmfPkg: PlatformPei: enable larger permanent PEI RAM
has made windows installs less reliable. From
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-win7-amd64/ovmf.html they mostly seem to be okay, or else we've gotten unluckY 3 in a row.
Ian, is the stickiness of the guest-stop (which is now an allowed fail
again) a coincidence or should we do something to unstick?
>
> Regressions which are regarded as allowable (not blocking):
> test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58919
>
> version targeted for testing:
> ovmf 79d274b8b6b113248661c18f31c4be03c7da32de
> baseline version:
> ovmf 495ee9b85141dd9b65434d677b3a685fe166128d
>
> ------------------------------------------------------------
> People who touched revisions under test:
> Laszlo Ersek <lersek@redhat.com>
> Maoming <maoming.maoming@huawei.com>
> Wei Liu <wei.liu2@citrix.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-debianhvm-amd64-xsm pass
> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
> test-amd64-i386-qemuu-rhel6hvm-amd pass
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
> test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
> test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
> test-amd64-i386-xl-qemuu-ovmf-amd64 pass
> test-amd64-amd64-xl-qemuu-win7-amd64 fail
> test-amd64-i386-xl-qemuu-win7-amd64 fail
> test-amd64-i386-qemuu-rhel6hvm-intel pass
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
> test-amd64-amd64-xl-qemuu-winxpsp3 pass
> test-amd64-i386-xl-qemuu-winxpsp3 pass
>
>
> ------------------------------------------------------------
> 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
>
> Test harness code can be found at
> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
>
>
> Not pushing.
>
> ------------------------------------------------------------
> commit 79d274b8b6b113248661c18f31c4be03c7da32de
> Author: Laszlo Ersek <lersek@redhat.com>
> Date: Fri Jun 26 16:09:52 2015 +0000
>
> OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
>
> At the moment we work with a UC default MTRR type, and set three memory
> ranges to WB:
> - [0, 640 KB),
> - [1 MB, LowerMemorySize),
> - [4 GB, 4 GB + UpperMemorySize).
>
> Unfortunately, coverage for the third range can fail with a high
> likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
> the size (UpperMemorySize) differ, then MtrrLib creates a series of
> variable MTRR entries, with power-of-two sized MTRR masks. And, it's
> really easy to run out of variable MTRR entries, dependent on the
> alignment difference.
>
> This is a problem because a Linux guest will loudly reject any high memory
> that is not covered my MTRR.
>
> So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
> - flip the MTRR default type to WB,
> - set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
> type and variable MTRRs, so we can't avoid this,
> - set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
> - set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
> more likely than the other scheme (due to less chaotic alignment
> differences).
>
> Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000)
> in PcdDebugPrintErrorLevel.
>
> Cc: Maoming <maoming.maoming@huawei.com>
> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Tested-by: Maoming <maoming.maoming@huawei.com>
> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
>
> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17722 6f19259b-4bc3-4df7-8a09-765794883524
>
> commit cfc80e2e95ee639e240c09eaeab76c0286bf917e
> Author: Laszlo Ersek <lersek@redhat.com>
> Date: Fri Jun 26 16:09:48 2015 +0000
>
> OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
>
> Build the memory HOBs in a tight block, in increasing base address order.
>
> Cc: Maoming <maoming.maoming@huawei.com>
> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Tested-by: Maoming <maoming.maoming@huawei.com>
> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
>
> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17721 6f19259b-4bc3-4df7-8a09-765794883524
>
> commit 86a14b0a7b89d5c301a167fa71ab765f56b878f0
> Author: Laszlo Ersek <lersek@redhat.com>
> Date: Fri Jun 26 16:09:43 2015 +0000
>
> OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
>
> Maoming reported that guest memory sizes equal to or larger than 64GB
> were not correctly handled by OVMF.
>
> Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and
> starting QEMU with 64GB guest RAM size, I found the following error in the
> OVMF debug log:
>
> > GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000)
> > GcdMemoryType = Reserved
> > Capabilities = 030000000000000F
> > Status = Unsupported
>
> This message is emitted when the DXE core is initializing the memory space
> map, processing the "above 4GB" memory resource descriptor HOB that was
> created by OVMF's QemuInitializeRam() function (see "UpperMemorySize").
>
> The DXE core's call chain fails in:
>
> CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
> CoreConvertSpace()
> //
> // Search for the list of descriptors that cover the range BaseAddress
> // to BaseAddress+Length
> //
> CoreSearchGcdMapEntry()
>
> CoreSearchGcdMapEntry() fails because the one entry (with type
> "nonexistent") in the initial GCD memory space map is too small, and
> cannot be split to cover the memory space range being added:
>
> > GCD:Initial GCD Memory Space Map
> > GCDMemType Range Capabilities Attributes
> > ========== ================================= ================ ================
> > NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000
>
> The size of this initial entry is determined from the CPU HOB
> (CoreInitializeGcdServices()).
>
> Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth,
> which is the narrowest valid value to cover the entire guest RAM.
>
> Reported-by: Maoming <maoming.maoming@huawei.com>
> Cc: Maoming <maoming.maoming@huawei.com>
> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Tested-by: Wei Liu <wei.liu2@citrix.com>
> Tested-by: Maoming <maoming.maoming@huawei.com>
> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
>
> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
>
> commit bc89fe4879012b3d8e0b8f7a73bc0b2c122db5ad
> Author: Laszlo Ersek <lersek@redhat.com>
> Date: Fri Jun 26 16:09:39 2015 +0000
>
> OvmfPkg: PlatformPei: enable larger permanent PEI RAM
>
> We'll soon increase the maximum guest-physical RAM size supported by OVMF.
> For more RAM, the DXE IPL is going to build more page tables, and for that
> it's going to need a bigger chunk from the permanent PEI RAM.
>
> Otherwise CreateIdentityMappingPageTables() would fail with:
>
> > DXE IPL Entry
> > Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi
> > Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260
> > AllocatePages failed: No 0x40201 Pages is available.
> > There is only left 0x3F1F pages memory resource to be allocated.
> > ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123):
> > BigPageAddress != 0
>
> (The above example belongs to the artificially high, maximal address width
> of 52, clamped by the DXE core to 48. The address width of 48 bits
> corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging
> structures.)
>
> Cc: Maoming <maoming.maoming@huawei.com>
> Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Brian J. Johnson <bjohnson@sgi.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> Reviewed-by: Brian J. Johnson <bjohnson@sgi.com>
> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
>
> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ovmf test] 58956: regressions - FAIL
2015-06-29 9:32 ` Ian Campbell
@ 2015-06-30 16:53 ` Anthony PERARD
2015-07-01 8:55 ` Ian Campbell
0 siblings, 1 reply; 5+ messages in thread
From: Anthony PERARD @ 2015-06-30 16:53 UTC (permalink / raw)
To: Ian Campbell; +Cc: Wei Liu, xen-devel, ian.jackson
On Mon, Jun 29, 2015 at 10:32:43AM +0100, Ian Campbell wrote:
> On Sun, 2015-06-28 at 22:32 +0000, osstest service user wrote:
> > flight 58956 ovmf real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/58956/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58919
>
> http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-win7-amd64.windows-install.html smells like something in the range:
> $ git log --oneline 495ee9b85..79d274b8b
> 79d274b OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> cfc80e2 OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
> 86a14b0 OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
> bc89fe4 OvmfPkg: PlatformPei: enable larger permanent PEI RAM
>
> has made windows installs less reliable. From
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-win7-amd64/ovmf.html they mostly seem to be okay, or else we've gotten unluckY 3 in a row.
Wait we are testing win7 install with OVMF in osstest? Did you made a new
iso that is capable of EFI booting? Also I don't think I've ever found a
win7 iso within Citrix that was capables of booting with OVMF. But I
haven't look very hard either.
Looking at the guest config, I don't see any mention of using OVMF instead
of SeaBIOS.
http://logs.test-lab.xenproject.org/osstest/logs/58956/test-amd64-i386-xl-qemuu-win7-amd64/fiano1---etc-xen-win.guest.osstest.cfg
So, I guest OVMF have nothing to do with the failure.
--
Anthony PERARD
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ovmf test] 58956: regressions - FAIL
2015-06-30 16:53 ` Anthony PERARD
@ 2015-07-01 8:55 ` Ian Campbell
2015-07-06 18:02 ` Wei Liu
0 siblings, 1 reply; 5+ messages in thread
From: Ian Campbell @ 2015-07-01 8:55 UTC (permalink / raw)
To: Anthony PERARD; +Cc: Wei Liu, xen-devel, ian.jackson
On Tue, 2015-06-30 at 17:53 +0100, Anthony PERARD wrote:
> On Mon, Jun 29, 2015 at 10:32:43AM +0100, Ian Campbell wrote:
> > On Sun, 2015-06-28 at 22:32 +0000, osstest service user wrote:
> > > flight 58956 ovmf real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/58956/
> > >
> > > Regressions :-(
> > >
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > > test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58919
> >
> > http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-win7-amd64.windows-install.html smells like something in the range:
> > $ git log --oneline 495ee9b85..79d274b8b
> > 79d274b OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> > cfc80e2 OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
> > 86a14b0 OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
> > bc89fe4 OvmfPkg: PlatformPei: enable larger permanent PEI RAM
> >
> > has made windows installs less reliable. From
> > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-win7-amd64/ovmf.html they mostly seem to be okay, or else we've gotten unluckY 3 in a row.
>
> Wait we are testing win7 install with OVMF in osstest? Did you made a new
> iso that is capable of EFI booting? Also I don't think I've ever found a
> win7 iso within Citrix that was capables of booting with OVMF. But I
> haven't look very hard either.
>
> Looking at the guest config, I don't see any mention of using OVMF instead
> of SeaBIOS.
> http://logs.test-lab.xenproject.org/osstest/logs/58956/test-amd64-i386-xl-qemuu-win7-amd64/fiano1---etc-xen-win.guest.osstest.cfg
>
> So, I guest OVMF have nothing to do with the failure.
Yes, it looks like you are right from the runvars of 58956:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 bios seabios
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm bios seabios
test-amd64-amd64-xl-qemuu-ovmf-amd64 bios ovmf
test-amd64-i386-xl-qemuu-debianhvm-amd64 bios seabios
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm bios seabios
test-amd64-i386-xl-qemuu-ovmf-amd64 bios ovmf
+ there are tests with no bios specified at all (=> gets the default = seabios):
test-amd64-amd64-xl-qemuu-win7-amd64
test-amd64-amd64-xl-qemuu-winxpsp3
test-amd64-i386-qemuu-rhel6hvm-amd
test-amd64-i386-qemuu-rhel6hvm-intel
test-amd64-i386-xl-qemuu-win7-amd64
test-amd64-i386-xl-qemuu-winxpsp3
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1
Wei, is that expected? (sorry if I've misremembered who added these
tests...)
Is the fix to stop wasting time with some of those tests on the ovmf
branch or to switch them to ovmf variants (or some combination of the
two)?
Ian.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ovmf test] 58956: regressions - FAIL
2015-07-01 8:55 ` Ian Campbell
@ 2015-07-06 18:02 ` Wei Liu
0 siblings, 0 replies; 5+ messages in thread
From: Wei Liu @ 2015-07-06 18:02 UTC (permalink / raw)
To: Ian Campbell; +Cc: Anthony PERARD, Wei Liu, xen-devel, ian.jackson
On Wed, Jul 01, 2015 at 09:55:27AM +0100, Ian Campbell wrote:
> On Tue, 2015-06-30 at 17:53 +0100, Anthony PERARD wrote:
> > On Mon, Jun 29, 2015 at 10:32:43AM +0100, Ian Campbell wrote:
> > > On Sun, 2015-06-28 at 22:32 +0000, osstest service user wrote:
> > > > flight 58956 ovmf real [real]
> > > > http://logs.test-lab.xenproject.org/osstest/logs/58956/
> > > >
> > > > Regressions :-(
> > > >
> > > > Tests which did not succeed and are blocking,
> > > > including tests which could not be run:
> > > > test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 58919
> > >
> > > http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-win7-amd64.windows-install.html smells like something in the range:
> > > $ git log --oneline 495ee9b85..79d274b8b
> > > 79d274b OvmfPkg: PlatformPei: invert MTRR setup in QemuInitializeRam()
> > > cfc80e2 OvmfPkg: PlatformPei: beautify memory HOB order in QemuInitializeRam()
> > > 86a14b0 OvmfPkg: PlatformPei: create the CPU HOB with dynamic memory space width
> > > bc89fe4 OvmfPkg: PlatformPei: enable larger permanent PEI RAM
> > >
> > > has made windows installs less reliable. From
> > > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemuu-win7-amd64/ovmf.html they mostly seem to be okay, or else we've gotten unluckY 3 in a row.
> >
> > Wait we are testing win7 install with OVMF in osstest? Did you made a new
> > iso that is capable of EFI booting? Also I don't think I've ever found a
> > win7 iso within Citrix that was capables of booting with OVMF. But I
> > haven't look very hard either.
> >
> > Looking at the guest config, I don't see any mention of using OVMF instead
> > of SeaBIOS.
> > http://logs.test-lab.xenproject.org/osstest/logs/58956/test-amd64-i386-xl-qemuu-win7-amd64/fiano1---etc-xen-win.guest.osstest.cfg
> >
> > So, I guest OVMF have nothing to do with the failure.
>
> Yes, it looks like you are right from the runvars of 58956:
>
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 bios seabios
> test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm bios seabios
> test-amd64-amd64-xl-qemuu-ovmf-amd64 bios ovmf
> test-amd64-i386-xl-qemuu-debianhvm-amd64 bios seabios
> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm bios seabios
> test-amd64-i386-xl-qemuu-ovmf-amd64 bios ovmf
>
> + there are tests with no bios specified at all (=> gets the default = seabios):
>
> test-amd64-amd64-xl-qemuu-win7-amd64
> test-amd64-amd64-xl-qemuu-winxpsp3
> test-amd64-i386-qemuu-rhel6hvm-amd
> test-amd64-i386-qemuu-rhel6hvm-intel
> test-amd64-i386-xl-qemuu-win7-amd64
> test-amd64-i386-xl-qemuu-winxpsp3
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1
>
> Wei, is that expected? (sorry if I've misremembered who added these
> tests...)
>
Yes, that's expected.
> Is the fix to stop wasting time with some of those tests on the ovmf
> branch or to switch them to ovmf variants (or some combination of the
> two)?
>
I was expecting we would eventually support ovmf variants for all HVM
related tests. But that doesn't seem to be realistic in the near future.
For now stopping wasting time on those tests on ovmf branch would be
a good thing to have.
Wei.
> Ian.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-07-06 18:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-28 22:32 [ovmf test] 58956: regressions - FAIL osstest service user
2015-06-29 9:32 ` Ian Campbell
2015-06-30 16:53 ` Anthony PERARD
2015-07-01 8:55 ` Ian Campbell
2015-07-06 18:02 ` Wei Liu
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.