[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [ovmf test] 58956: regressions - FAIL



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.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.