>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.
Hi Alex and Liuqing,
I hesitate the xenU cases failure issue is caused by the changeset after 15659,
as we didn't catch xenU failure (can not open tty console) before Changeset
15659.
For the xend hang issue, we also catch it in IA32 side. Keir said it should be
fixed at 15671:0c79a9414f8d (xen-unstable). When this issue happen, VTI domain
also can not be created.
Best Regards,
Yongkang You
>-----Original Message-----
>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf
>Of Yang, Liuqing
>Sent: Thursday, August 02, 2007 11:34 AM
>To: Alex Williamson
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [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
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home