VMX nightly testing for Xen:#17269 is blocked

VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~ c/s
17269), regression is introduced accordingly.

Today's nightly testing for Xen:#17269 is blocked by following issue:

Bug #1194, both Linux and Windows HVM guest can not boot up,
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.



-- haicheng

Re: VMX nightly testing for Xen:#17269 is blocked

[Keir Fraser]

Interesting. I managed to install a Windows XP guest, but it took *ages* (at
least twice as long as usual, and actually probably more than that).

The changeset referenced in the bug ticket might well be a red herring.
Probably it is best to binary-chop on the Linux boot failure to find the
offending changeset for that.

 -- Keir

On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:

> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~ c/s
> 17269), regression is introduced accordingly.
> 
> Today's nightly testing for Xen:#17269 is blocked by following issue:
> 
> Bug #1194, both Linux and Windows HVM guest can not boot up,
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
> 
> 
> 
> -- haicheng
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: VMX nightly testing for Xen:#17269 is blocked

[Keir Fraser]

Actually your ttyS0 logging is also interesting. MMIO emulation is failing
on an instruction with prefix "0f 6f", which is MOVQ. It's not clear,
though, whether MOVQ is *really* supposed to be emulated -- I don't think
the old MMIO emulator emulated MOVQ either, so this may indicate that
execution went wrong sometime earlier.

 -- Keir

On 21/3/08 09:19, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:

> Interesting. I managed to install a Windows XP guest, but it took *ages* (at
> least twice as long as usual, and actually probably more than that).
> 
> The changeset referenced in the bug ticket might well be a red herring.
> Probably it is best to binary-chop on the Linux boot failure to find the
> offending changeset for that.
> 
>  -- Keir
> 
> On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:
> 
>> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~ c/s
>> 17269), regression is introduced accordingly.
>> 
>> Today's nightly testing for Xen:#17269 is blocked by following issue:
>> 
>> Bug #1194, both Linux and Windows HVM guest can not boot up,
>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
>> 
>> 
>> 
>> -- haicheng
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

Keir, we double checked this bug and found there should be two different
bugs in c/s 17269:

Bug 1: SDL library related issue: Linux X window and Windows OS failed
to initialize:
	a. if using SDL lib, Windows / Linux X will stop and then qemu
window will disappear.
	b. if using VNC lib, Windows / Linux X can boot successfully.

Bug 2: Linux booting hang with "hda: dma..." errors. Dexuan Cui has
found the root cause and he will give more updates for this bug.


Keir Fraser wrote:
> Interesting. I managed to install a Windows XP guest, but it took
> *ages* (at least twice as long as usual, and actually probably more
> than that). 
> 
> The changeset referenced in the bug ticket might well be a red
> herring. Probably it is best to binary-chop on the Linux boot failure
> to find the offending changeset for that.
> 
>  -- Keir
> 
> On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:
> 
>> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~
>> c/s 17269), regression is introduced accordingly.
>> 
>> Today's nightly testing for Xen:#17269 is blocked by following issue:
>> 
>> Bug #1194, both Linux and Windows HVM guest can not boot up,
>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
>> 
>> 
>> 
>> -- haicheng
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel



-- haicheng

Re: VMX nightly testing for Xen:#17269 is blocked

[Keir Fraser]

Bug #1 is almost certainly due to one of Stefano's patches. He's now cc'ed.

Obvious suspect is the SDL OpenGL rendering patches. You could try adding
opengl=0 to your guest config file, or reverting the changesets relating to
sdl/opengl (there are 3 or 4 of them).

 -- Keir

On 21/3/08 09:46, "Li, Haicheng" <haicheng.li@intel.com> wrote:

> Keir, we double checked this bug and found there should be two different
> bugs in c/s 17269:
> 
> Bug 1: SDL library related issue: Linux X window and Windows OS failed
> to initialize:
> a. if using SDL lib, Windows / Linux X will stop and then qemu
> window will disappear.
> b. if using VNC lib, Windows / Linux X can boot successfully.
> 
> Bug 2: Linux booting hang with "hda: dma..." errors. Dexuan Cui has
> found the root cause and he will give more updates for this bug.
> 
> 
> Keir Fraser wrote:
>> Interesting. I managed to install a Windows XP guest, but it took
>> *ages* (at least twice as long as usual, and actually probably more
>> than that). 
>> 
>> The changeset referenced in the bug ticket might well be a red
>> herring. Probably it is best to binary-chop on the Linux boot failure
>> to find the offending changeset for that.
>> 
>>  -- Keir
>> 
>> On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:
>> 
>>> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~
>>> c/s 17269), regression is introduced accordingly.
>>> 
>>> Today's nightly testing for Xen:#17269 is blocked by following issue:
>>> 
>>> Bug #1194, both Linux and Windows HVM guest can not boot up,
>>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
>>> 
>>> 
>>> 
>>> -- haicheng
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
> 
> 
> 
> -- haicheng

RE: VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

Yes, with opengl=0 added in guest config, bug1 disappears, both Linux X
and Windows can boot up with SDL lib. Thanks.

Keir Fraser wrote:
> Bug #1 is almost certainly due to one of Stefano's patches. He's now
> cc'ed. 
> 
> Obvious suspect is the SDL OpenGL rendering patches. You could try
> adding opengl=0 to your guest config file, or reverting the
> changesets relating to sdl/opengl (there are 3 or 4 of them).
> 
>  -- Keir
> 
> On 21/3/08 09:46, "Li, Haicheng" <haicheng.li@intel.com> wrote:
> 
>> Keir, we double checked this bug and found there should be two
>> different bugs in c/s 17269: 
>> 
>> Bug 1: SDL library related issue: Linux X window and Windows OS
>> failed to initialize: a. if using SDL lib, Windows / Linux X will
>> stop and then qemu 
>> window will disappear.
>> b. if using VNC lib, Windows / Linux X can boot successfully.
>> 
>> Bug 2: Linux booting hang with "hda: dma..." errors. Dexuan Cui has
>> found the root cause and he will give more updates for this bug.
>> 
>> 
>> Keir Fraser wrote:
>>> Interesting. I managed to install a Windows XP guest, but it took
>>> *ages* (at least twice as long as usual, and actually probably more
>>> than that). 
>>> 
>>> The changeset referenced in the bug ticket might well be a red
>>> herring. Probably it is best to binary-chop on the Linux boot
>>> failure to find the offending changeset for that.
>>> 
>>>  -- Keir
>>> 
>>> On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:
>>> 
>>>> Since 76 changesets are added to Xen-unsable tree today (c/s 17194
>>>> ~ c/s 17269), regression is introduced accordingly.
>>>> 
>>>> Today's nightly testing for Xen:#17269 is blocked by following
>>>> issue: 
>>>> 
>>>> Bug #1194, both Linux and Windows HVM guest can not boot up,
>>>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
>>>> 
>>>> 
>>>> 
>>>> -- haicheng
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@lists.xensource.com
>>>> http://lists.xensource.com/xen-devel
>> 
>> 
>> 
>> -- haicheng



-- haicheng

Re: VMX nightly testing for Xen:#17269 is blocked

[Samuel Thibault]

Li, Haicheng, le Fri 21 Mar 2008 17:46:32 +0800, a écrit :
> Keir, we double checked this bug and found there should be two different
> bugs in c/s 17269:
> 
> Bug 1: SDL library related issue: Linux X window and Windows OS failed
> to initialize:
> 	a. if using SDL lib, Windows / Linux X will stop and then qemu
> window will disappear.

Mmm, I can't reproduce that.  At which step of boot does it stop?
Could you tell the exact configuration of Windows/Linux?
Are there useful information in /var/log/xen/qemu-dm-yourdomain.log?

Samuel

RE: VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Samuel Thibault wrote:
> Li, Haicheng, le Fri 21 Mar 2008 17:46:32 +0800, a écrit :
>> Keir, we double checked this bug and found there should be two
>> different bugs in c/s 17269: 
>> 
>> Bug 1: SDL library related issue: Linux X window and Windows OS
>> 	failed to initialize: a. if using SDL lib, Windows / Linux X will
>> stop and then qemu 
>> window will disappear.

with opengl=0 added in guest config, bug1 disappears, both Linux X and Windows can boot up with SDL lib. 

> Mmm, I can't reproduce that.  At which step of boot does it stop?
Actually since qemu window disappears immediately after OS enters graphic mode, it's hard to locate the exact step.
Only can say it is just after `startx &`  on Linux and "driver loading progress bar" on Windows. 

> Could you tell the exact configuration of Windows/Linux?
Guest config file is attached.

> Are there useful information in /var/log/xen/qemu-dm-yourdomain.log?
Seems no useful info for this bug in qemu log. The log is attached too.



-- haicheng

[-- Attachment #2: qemu-dm-pci0_vm.log --]
[-- Type: application/octet-stream, Size: 1569 bytes --]

domid: 1
qemu: the number of cpus is 1
Watching /local/domain/0/device-model/1/logdirty/next-active
Watching /local/domain/0/device-model/1/command
char device redirected to /dev/pts/3
qemu_map_cache_init nr_buckets = 10000 size 3145728
shared page at pfn 1ffff
buffered io page at pfn 1fffd
Time offset set 0
Register xen platform.
Done register platform.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
gpe_en_write: addr=0x1f6c, val=0x0.
gpe_sts_write: addr=0x1f68, val=0xff.
gpe_en_write: addr=0x1f6d, val=0x0.
gpe_sts_write: addr=0x1f69, val=0xff.
gpe_en_write: addr=0x1f6e, val=0x0.
gpe_sts_write: addr=0x1f6a, val=0xff.
gpe_en_write: addr=0x1f6f, val=0x0.
gpe_sts_write: addr=0x1f6b, val=0xff.
gpe_en_write: addr=0x1f6c, val=0x8.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.

[-- Attachment #3: hvm-guest.conf --]
[-- Type: application/octet-stream, Size: 7827 bytes --]

#  -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or 
# you can set the parameters for the domain on the xm command line.
#============================================================================

import os, re
arch = os.uname()[4]
if re.search('64', arch):
    arch_libdir = 'lib64'
else:
    arch_libdir = 'lib'

#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"

# The domain build function. HVM domain uses 'hvm'.
builder='hvm'

# Initial memory allocation (in megabytes) for the new domain.
#
# WARNING: Creating a domain with insufficient memory may cause out of
#          memory errors. The domain needs enough memory to boot kernel
#          and modules. Allocating less than 32MBs is not recommended.
memory = 512 

# Shadow pagetable memory for the domain, in MB.
# If not explicictly set, xend will pick an appropriate value.  
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 8

# A name for your domain. All domains must have different names.
name = "pci0_vm"

# 128-bit UUID for the domain.  The default behavior is to generate a new UUID
# on each call to 'xm create'.
#uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"

#-----------------------------------------------------------------------------
# The number of cpus guest platform has, default=1

# Enable/disable HVM guest PAE, default=1 (enabled)
pae=1

# Enable/disable HVM guest ACPI, default=1 (enabled)
acpi=1

# Enable/disable HVM APIC mode, default=1 (enabled)
# Note that this option is ignored if vcpus > 1
apic=1

# List of which CPUS this domain is allowed to use, default Xen picks
#cpus = ""         # leave to Xen to pick
#cpus = "0"        # all vcpus run on CPU0
#cpus = "0-3,5,^1" # run on cpus 0,2,3,5

# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'type=ioemu, mac=00:16:3e:00:00:11, bridge=xenbr0, model=ne2k_pci' ]
# type=ioemu specify the NIC is an ioemu device not netfront
#vif = [ 'type=ioemu, bridge=eth1' ]
#vif = [ 'type=ioemu, bridge=eth0' ]
#vif = [ 'type=netfront, bridge=eth0' ]
#vif = [ 'type=ioemu' ]

#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.

disk = [ 'file:/root/ia32e_fc7.qcow,hda,w']

#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits.  There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash.  For each of these you
# may specify:
#
#   "destroy",        meaning that the domain is cleaned up as normal;
#   "restart",        meaning that a new domain is started in place of the old
#                     one;
#   "preserve",       meaning that no clean-up is done until the domain is
#                     manually destroyed (using xm destroy, for example); or
#   "rename-restart", meaning that the old domain is not cleaned up, but is
#                     renamed and a new domain started in its place.
#
# The default is
#
#   on_poweroff = 'destroy'
#   on_reboot   = 'restart'
#   on_crash    = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
#                            on_reboot   = 'restart'
#                            on_crash    = 'destroy'
#
# restart = 'always'   means on_poweroff = 'restart'
#                            on_reboot   = 'restart'
#                            on_crash    = 'restart'
#
# restart = 'never'    means on_poweroff = 'destroy'
#                            on_reboot   = 'destroy'
#                            on_crash    = 'destroy'

#on_poweroff = 'destroy'
#on_reboot   = 'restart'
#on_crash    = 'restart'
#on_poweroff = 'preserve'
#on_reboot   = 'preserve'
#on_crash    = 'preserve'

#============================================================================

# New stuff
device_model = '/usr/' + arch_libdir + '/xen/bin/qemu-dm'

#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c), Network (n) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy
#boot="cda"

#-----------------------------------------------------------------------------
#  write to temporary files instead of disk image files
#snapshot=1

#----------------------------------------------------------------------------
# enable SDL library for graphics, default = 0
sdl=1

#----------------------------------------------------------------------------
# enable VNC library for graphics, default = 1
vnc=0

#----------------------------------------------------------------------------
# address that should be listened on for the VNC server if vnc is set.
# default is to use 'vnc-listen' setting from /etc/xen/xend-config.sxp
#vnclisten="127.0.0.1"

#----------------------------------------------------------------------------
# set VNC display number, default = domid
#vncdisplay=2

#----------------------------------------------------------------------------
# try to find an unused port for the VNC server, default = 1
#vncunused=1

#----------------------------------------------------------------------------
# enable spawning vncviewer for domain's console
# (only valid when vnc=1), default = 0
vncconsole=1

#----------------------------------------------------------------------------
# set password for domain's VNC console
# default is depents on vncpasswd in xend-config.sxp
vncpasswd=''

#----------------------------------------------------------------------------
# no graphics, use serial port
#nographic=0

#----------------------------------------------------------------------------
# enable stdvga, default = 0 (use cirrus logic device model)
stdvga=0

#-----------------------------------------------------------------------------
#   serial port re-direct to pty deivce, /dev/pts/n 
#   then xm console or minicom can connect
serial='pty'


#-----------------------------------------------------------------------------
#   Qemu Monitor, default is disable
#   Use ctrl-alt-2 to connect
monitor=1


#-----------------------------------------------------------------------------
#   enable sound card support, [sb16|es1370|all|..,..], default none
#soundhw='sb16'


#-----------------------------------------------------------------------------
#    set the real time clock to local time [default=0 i.e. set to utc]
#localtime=1


#-----------------------------------------------------------------------------
#    set the real time clock offset in seconds [default=0 i.e. same as dom0]
#rtc_timeoffset=3600

#-----------------------------------------------------------------------------
#    start in full screen
#full-screen=1   


#-----------------------------------------------------------------------------
#   Enable USB support (specific devices specified at runtime through the
#			monitor window)
#usb=1

#   Enable USB mouse support (only enable one of the following, `mouse' for
#			      PS/2 protocol relative mouse, `tablet' for
#			      absolute mouse)
#usbdevice='mouse'
#usbdevice='tablet'

#-----------------------------------------------------------------------------
#   Set keyboard layout, default is en-us keyboard. 
#keymap='ja'


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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

Re: VMX nightly testing for Xen:#17269 is blocked

[Samuel Thibault]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Li, Haicheng, le Fri 21 Mar 2008 21:02:30 +0800, a écrit :
> Actually since qemu window disappears immediately after OS enters graphic mode, it's hard to locate the exact step.
> Only can say it is just after `startx &`  on Linux and "driver loading progress bar" on Windows. 

Ok, so that's when we switch to OpenGL rendering.

> > Could you tell the exact configuration of Windows/Linux?
> Guest config file is attached.

Well, I meant the guest configuration actually (resolution/color depth).

> > Are there useful information in /var/log/xen/qemu-dm-yourdomain.log?
> Seems no useful info for this bug in qemu log.

Indeed :/

Could you try to use the attached qemu-dm.gdb script for the device
model?  It is just a gdb wrapper around the actual qemu-dm, which should
let get a backtrace.

Samuel

[-- Attachment #2: qemu-dm.gdb --]
[-- Type: text/plain, Size: 153 bytes --]

#!/bin/sh

if [ "`arch`" = "x86_64" ]; then
    LIBDIR="lib64"
else
    LIBDIR="lib"
fi
xterm -e /bin/sh -c "gdb --args /usr/$LIBDIR/xen/bin/qemu-dm $*"

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

RE: VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

Samuel Thibault wrote:
> Li, Haicheng, le Fri 21 Mar 2008 21:02:30 +0800, a écrit :
>> Actually since qemu window disappears immediately after OS enters
>> graphic mode, it's hard to locate the exact step. Only can say it is
>> just after `startx &`  on Linux and "driver loading progress bar" on
>> Windows.  
> 
> Ok, so that's when we switch to OpenGL rendering.
> 
>>> Could you tell the exact configuration of Windows/Linux? Guest
>>> config file is attached. 
> 
> Well, I meant the guest configuration actually (resolution/color
> depth). 

Resolution: 800 * 600, color: 24 bit.

>>> Are there useful information in /var/log/xen/qemu-dm-yourdomain.log?
>> Seems no useful info for this bug in qemu log.
> 
> Indeed :/
> 
> Could you try to use the attached qemu-dm.gdb script for the device
> model?  It is just a gdb wrapper around the actual qemu-dm, which
> should let get a backtrace.

There is a segment fault caused by sdl_resize() in tools/ioemu/sdl.c. 
I changed a few code as below and found SDL_SetVideoMode() failed with error:Couldn't find matching GLX visual. 
And detailed qemu log is attached.

==

diff -r 76c9cf11ce23 tools/ioemu/sdl.c
--- a/tools/ioemu/sdl.c	Fri Mar 21 09:45:34 2008 +0000
+++ b/tools/ioemu/sdl.c	Mon Mar 24 16:49:09 2008 +0800
@@ -191,15 +191,18 @@ static void sdl_resize(DisplayState *ds,
 {
     int flags;
 
-    //    printf("resizing to %d %d\n", w, h);
+    printf("resizing to %d %d\n", w, h);
 
 #ifdef CONFIG_OPENGL
     if (ds->shared_buf && opengl_enabled)
         flags = SDL_OPENGL|SDL_RESIZABLE;
     else
 #endif
-        flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_HWPALETTE;
-
+	flags = SDL_HWSURFACE|SDL_ASYNCBLIT|SDL_HWACCEL|SDL_DOUBLEBUF|SDL_HWPALETTE;
+
+#ifdef CONFIG_OPENGL
+    printf("opengl is defined\n");
+#endif
     if (gui_fullscreen) {
         flags |= SDL_FULLSCREEN;
         flags &= ~SDL_RESIZABLE;
@@ -210,11 +213,11 @@ static void sdl_resize(DisplayState *ds,
 
  again:
     screen = SDL_SetVideoMode(w, h, 0, flags);
-#ifndef CONFIG_OPENGL
     if (!screen) {
         fprintf(stderr, "Could not open SDL display: %s\n", SDL_GetError());
         exit(1);
     }
+#ifndef CONFIG_OPENGL
     if (!screen->pixels && (flags & SDL_HWSURFACE) && (flags & SDL_FULLSCREEN)) {
         flags &= ~SDL_HWSURFACE;
         goto again;




-- haicheng

[-- Attachment #2: qemu-log.txt --]
[-- Type: text/plain, Size: 2136 bytes --]

From: root [root@vt-wb3]
Sent: 2008Äê3ÔÂ24ÈÕÐÇÆÚÒ» 16:57
To: Li, Haicheng

domid: 39
qemu: the number of cpus is 1
Watching /local/domain/0/device-model/39/logdirty/next-active
Watching /local/domain/0/device-model/39/command
resizing to 640 400
opengl is defined
char device redirected to /dev/pts/8
qemu_map_cache_init nr_buckets = 10000 size 3145728
shared page at pfn 3ffff
buffered io page at pfn 3fffd
Time offset set 0
Register xen platform.
Done register platform.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
resizing to 720 400
opengl is defined
resizing to 640 480
opengl is defined
gpe_sts_write: addr=0x1f68, val=0x0.
gpe_sts_write: addr=0x1f69, val=0x0.
gpe_sts_write: addr=0x1f6a, val=0x0.
gpe_sts_write: addr=0x1f6b, val=0x0.
gpe_en_write: addr=0x1f6c, val=0x0.
gpe_en_write: addr=0x1f6d, val=0x0.
gpe_en_write: addr=0x1f6e, val=0x0.
gpe_en_write: addr=0x1f6f, val=0x0.
gpe_en_write: addr=0x1f6c, val=0x0.
gpe_en_write: addr=0x1f6d, val=0x0.
gpe_en_write: addr=0x1f6e, val=0x0.
gpe_en_write: addr=0x1f6f, val=0x0.
gpe_sts_write: addr=0x1f68, val=0x0.
gpe_sts_write: addr=0x1f69, val=0x0.
gpe_sts_write: addr=0x1f6a, val=0x0.
gpe_sts_write: addr=0x1f6b, val=0x0.
gpe_en_write: addr=0x1f6c, val=0x8.
gpe_en_write: addr=0x1f6d, val=0x0.
gpe_en_write: addr=0x1f6e, val=0x0.
gpe_en_write: addr=0x1f6f, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
ACPI PCI hotplug: read addr=0x10c1, val=0x0.
ACPI PCI hotplug: read addr=0x10c2, val=0x0.
resizing to 800 600
opengl is defined
Could not open SDL display: Couldn't find matching GLX visual

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: VMX nightly testing for Xen:#17269 is blocked

[Keir Fraser]

Dexuan's hvm_io_bitmap fix could account for any amount of HVM guest
weirdness. I pushed it straight through to the public tree, and let's hope
your next round of testing is unblocked.

 -- Keir

On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:

> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~ c/s
> 17269), regression is introduced accordingly.
> 
> Today's nightly testing for Xen:#17269 is blocked by following issue:
> 
> Bug #1194, both Linux and Windows HVM guest can not boot up,
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
> 
> 
> 
> -- haicheng
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: VMX nightly testing for Xen:#17269 is blocked

[Li, Haicheng]

Seems with Dexuan's patch, Windows guest with sdl=1 still fails to boot
up. I will double check it in next round testing.

Keir Fraser wrote:
> Dexuan's hvm_io_bitmap fix could account for any amount of HVM guest
> weirdness. I pushed it straight through to the public tree, and let's
> hope your next round of testing is unblocked.
> 
>  -- Keir
> 
> On 21/3/08 06:27, "Li, Haicheng" <haicheng.li@intel.com> wrote:
> 
>> Since 76 changesets are added to Xen-unsable tree today (c/s 17194 ~
>> c/s 17269), regression is introduced accordingly.
>> 
>> Today's nightly testing for Xen:#17269 is blocked by following issue:
>> 
>> Bug #1194, both Linux and Windows HVM guest can not boot up,
>> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1194.
>> 
>> 
>> 
>> -- haicheng
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



-- haicheng