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

RE: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#15666


  • To: "Alex Williamson" <alex.williamson@xxxxxx>
  • From: "Yang, Liuqing" <liuqing.yang@xxxxxxxxx>
  • Date: Thu, 2 Aug 2007 11:34:18 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 01 Aug 2007 20:31:51 -0700
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcfUNxgc1ewmZoSzRrKMeAtahaWrywAfHQzw
  • Thread-topic: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#15666

Hi, Alex,
About the SMPWin_SMPVTI_SMPxenU_Co case fail, the open guest firmware do not 
have this bug, but since the open guest firmware can not support our nightly 
test automatic test(it don’t have nvram file for windows vti automatic 
booting), so we do not use it now. And about the older guest firmware,in the 
SMPWin_SMPVTI_SMPxenU_Co case when booting linux vti it usually can not 
uncompressing  linux kernel immediately, so it will repeat uncompressing the 
linux kernel until it succeed.  

About XenU case fail, I have retested the changeset 15666, and I found that if 
I just tried only one xenU case it usually passed, and if I test more cases 
including xenU case sequentially, the bug usually occurred. But with changeset 
15659 this bug occurs rarely. 

Best Regards
Liuqing

-----Original Message-----
From: Alex Williamson [mailto:alex.williamson@xxxxxx] 
Sent: 2007年8月1日 20:25
To: Yang, Liuqing
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-ia64-devel] Xen/IA64 Healthiness Report -Cset#15666

On Wed, 2007-08-01 at 14:11 +0800, Yang, Liuqing wrote:
> Xen/IA64 Healthiness Report
> ----------------------------
> Six cases failed in this changeset. 
> All the xenU case failed because "xenconsole: Could not read tty from
> store: No such file or directory", and the bug can be reproduced
> easily now. xenU case boot fail since the last changeset 15665, and I
> have checked changeset 15659 it is OK.

Hi Liuqing,

   The previous testing on 15665 indicated this issue, but manual
testing passed.  What's changed that makes it so much more repeatable
now?  Changeset 15666 surely can't be contributing to this.  I've
noticed some semi-random failures with xm for a while (mainly it gets
into a state where most xm commands hang), but I haven't been able to
characterize what causes it.  Going back to cset 15659 would implicate
the pkr patches, but I've created plenty of PV domains with those
patches in place.  Any ideas?

> SMPWin_SMPVTI_SMPxenU_Co case still failed due to Linux VTI created
> fail with xenu and windows vti created at the same time. Error
> information printed to the Screen is "Exit status: Load Error Boot
> Succeeded". And return to the bios phrase.  When I checked this
> changeset with the older GFW(2007.5.15), then in the linux vti booting
> process it will try uncompressing the linux kernel many times until
> success. But an older changeset(14366), it do not have this issue.

   With the older GFW, where was the retry of the uncompress occurring?
I don't think elilo has support for this.  Was it the GFW retrying
elilo?  What happens with the open source GFW?  Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

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