Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
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@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
Could you try the following patch to ioemu?
NOTE:This is only a band aid patch. GFW needs modifcation.
ioemu: prevent qemu-dm segv.
With dade7f0bdc8d and old bios, qemu-dm results in segv.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 9b5e1e05e886 tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/cirrus_vga.c Fri Sep 05 12:42:37 2008 +0900
@@ -2553,7 +2553,11 @@
end = begin + VGA_RAM_SIZE;
fprintf(logfile,mapping vram to %lx - %lx\n, begin, end);
-
+if (!s-vram_mfns) {
+fprintf(logfile, Found old firmware skiping mapping vram\n);
+return;
+}
+
xatp.domid = domid;
xatp.space = XENMAPSPACE_mfn;
On Fri, Sep 05, 2008 at 11:32:28AM +0900, Isaku Yamahata wrote:
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@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
Isaku Yamahata wrote:
Could you try the following patch to ioemu?
NOTE:This is only a band aid patch. GFW needs modifcation.
ioemu: prevent qemu-dm segv.
With dade7f0bdc8d and old bios, qemu-dm results in segv.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 9b5e1e05e886 tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/cirrus_vga.c Fri Sep 05 12:42:37 2008 +0900
@@ -2553,7 +2553,11 @@
end = begin + VGA_RAM_SIZE;
fprintf(logfile,mapping vram to %lx - %lx\n, begin, end);
-
+if (!s-vram_mfns) {
+fprintf(logfile, Found old firmware skiping mapping
vram\n); +return;
+}
+
xatp.domid = domid;
xatp.space = XENMAPSPACE_mfn;
Hi Isaku,
I checked my building environment. My source were built twice by make -j3
and CONFIG_QEMU=ioemu make -j3. But they both use local ioemu (ia64 is
different with x86?). What command did you use to enable ioemu-remote?
So, remote-ioemu may not affect VTI booting, I will double check that with
your patch. Thanks.
Thanks,
Zhang Jingke
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
On Fri, Sep 05, 2008 at 11:43:55AM +0800, Zhang, Jingke wrote:
Isaku Yamahata wrote:
Could you try the following patch to ioemu?
NOTE:This is only a band aid patch. GFW needs modifcation.
ioemu: prevent qemu-dm segv.
With dade7f0bdc8d and old bios, qemu-dm results in segv.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 9b5e1e05e886 tools/ioemu/hw/cirrus_vga.c
--- a/tools/ioemu/hw/cirrus_vga.c Mon Sep 01 17:50:13 2008 +0900
+++ b/tools/ioemu/hw/cirrus_vga.c Fri Sep 05 12:42:37 2008 +0900
@@ -2553,7 +2553,11 @@
end = begin + VGA_RAM_SIZE;
fprintf(logfile,mapping vram to %lx - %lx\n, begin, end);
-
+if (!s-vram_mfns) {
+fprintf(logfile, Found old firmware skiping mapping
vram\n); +return;
+}
+
xatp.domid = domid;
xatp.space = XENMAPSPACE_mfn;
Hi Isaku,
I checked my building environment. My source were built twice by make
-j3 and CONFIG_QEMU=ioemu make -j3. But they both use local ioemu (ia64 is
different with x86?). What command did you use to enable ioemu-remote?
So, remote-ioemu may not affect VTI booting, I will double check that
with your patch. Thanks.
Hi Zhang.
Don't specify CONFIG_QEMU=ioemu or
specify
CONFIG_QEMU=http://xenbits.xensource.com/git-http/qemu-xen-unstable.git;
git command is necessary to build with ioemu-remote while building
it pulls the ioemu-remote tree from the above URL.
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
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! Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
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. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Xen/IPF Unstable CS#18421 StatusReport --- ioemu error
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. Thanks, Zhang Jingke ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
