WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu er

On Tue, Sep 02, 2008 at 03:02:20PM +0800, Zhang, Jingke wrote:
> Zhang, Jingke wrote:
> > Isaku Yamahata wrote:
> >> On Tue, Sep 02, 2008 at 11:22:27AM +0800, Zhang, Jingke wrote:
> >>> Hi all,
> >>>     We found all the VTI guests can not be booted up with this
> >>>     Cset#18421 (XenU can boot). Last test on Cset#18369 is good to
> >>> work. The failure is: when we boot up VTI, qemu will show a white
> >>> box and disappeared after 1 second. I have checked both local ioemu
> >>> and remote-ioemu, they both can not work. Did anyone find this by
> >>> using latest Xen-ia64?
> >>
> >> Hmm, I'm afraid that c/s 18394:dade7f0bdc8d causes it.
> >> Could you confirm that?
> >>
> >> I suppose that even if the window of virtual frame buffer dissapears,
> >> VTi guest OS is still working and serial console can be accessed.
> >> If so, GFW should be patched to tell qemu-dm where the virtual frame
> >> buffer memory is.
> >
> > Hi Isaku,
> >     I checked the console of VTI, it does not work. CPU time always
> >     stays 0.2 (guest should hang). Anyway, I will try 18394 to narrow
> > down this issue.
> >
> 
> Hi Isaku,
>     It should be as you said. 18394 caused the issue. I tested 18394, issue 
> exists. With 18393, VTI can be booted well. Thanks!

Hi Zhang.
I tried to reproduce it.
With ioemu, I confirmed it.
qemu-dm died from /var/log/xen/xend.log 
> model failure: pid 9584: died due to signal 11; see 
> /var/log/xen/qemu-dm-ExampleVTIDomain.log 

However with ioemu-remote, I wasn't able to reproduce the issue.
I couldn't find the corresponding patch looking changelog and source code.
I checked it with the following repository.
Am I looking at the wrong tree/branch/changeset?

repo:
        http://xenbits.xensource.com/git-http/staging/qemu-xen-unstable.git/
branch:
        mater
HEAD checksum
        77fba269deee38293b44ba5a1ce7ef4c39482975


Anyway I expect that the changeset will go to qemu-remote eventually,
we should address the issue.

-- 
yamahata

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