[Spice-devel] qemu crash on windows 7 resolution change on spice
Fabio Fantoni
fabio.fantoni at m2r.biz
Fri Jul 18 00:55:35 PDT 2014
Il 18/07/2014 04:01, kevin.zhang at octlink.com ha scritto:
> Hi Fabio Fantoni,
> I closed vnc options and can reproduce the problem, stack info is
> as follow:
>
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no
> debugging symbols found)...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> 0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
> (gdb) c
> Continuing.
> Program received signal SIGABRT, Aborted.
> 0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
> directory.
> (gdb) bt full
> #0 0x00007ffff2e04475 in *__GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> pid = <optimized out>
> selftid = <optimized out>
> #1 0x00007ffff2e076f0 in *__GI_abort () at abort.c:92
> act = {__sigaction_handler = {sa_handler =
> 0x7fffffffce58, sa_sigaction = 0x7fffffffce58}, sa_mask =
> {__val = {
> 140737488342592, 140737488348103, 33, 140737269326962, 1,
> 140737269331337, 3, 140737488342587, 5,
> 140737269327027, 1, 140737269336037, 3, 140737488342596, 12,
> 140737269336041}}, sa_flags = 2,
> sa_restorer = 0x7ffff2f207e9}
> sigs = {__val = {32, 0 <repeats 15 times>}}
> #2 0x00007ffff2e3f52b in __libc_message (do_abort=<optimized
> out>, fmt=<optimized out>)
> at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
> ap = {{gp_offset = 40, fp_offset = 48,
> overflow_arg_area = 0x7fffffffd7c0, reg_save_area =
> 0x7fffffffd6d0}}
> ap_copy = {{gp_offset = 16, fp_offset = 48,
> overflow_arg_area = 0x7fffffffd7c0, reg_save_area =
> 0x7fffffffd6d0}}
> fd = 2
> on_2 = <optimized out>
> list = <optimized out>
> nlist = 0
> cp = <optimized out>
> written = false
> #3 0x00007ffff2e48d76 in malloc_printerr (action=3,
> str=0x7ffff2f22908 "double free or corruption (!prev)",
> ptr=<optimized out>) at malloc.c:6312
> buf = "00007fffd4c390e0"
> cp = 0x0
> #4 0x00007ffff2e4db1c in *__GI___libc_free (mem=<optimized
> out>) at malloc.c:3738
> ar_ptr = 0x7fffd4000020
> p = 0x6
> #5 0x00007ffff3b5b44b in _pixman_image_fini
> (image=image at entry=0x7fffd4879820) at
> ../../pixman/pixman-image.c:173
> common = 0x7fffd4879820
> __PRETTY_FUNCTION__ = "_pixman_image_fini"
> #6 0x00007ffff3b5b399 in pixman_image_unref
> (image=0x7fffd4879820) at ../../pixman/pixman-image.c:211
> No locals.
> #7 0x000055555585283b in qemu_pixman_image_unref
> (image=0x7fffd4879820) at ui/qemu-pixman.c:80
> No locals.
> #8 0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048,
> surface=0x7fffd40b7c10) at ui/vnc.c:588
> vd = 0x7fffe2c99010
> vs = 0xff000000180420
> #9 0x000055555584be81 in dpy_gfx_replace_surface
> (con=0x5555566a90a0, surface=0x7fffd40b7c10) at ui/console.c:1404
> ---Type <return> to continue, or q <return> to quit---
> s = 0x5555565f64b0
> old_surface = 0x7fffd487a040
> dcl = 0x7fffe2c99048
> #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
> (qxl=0x5555566dba20) at hw/display/qxl-render.c:131
> vga = 0x5555566dc510
> surface = 0x7fffd40b7c10
> i = 0
> #11 0x00005555556ed021 in qxl_render_update_area_bh
> (opaque=0x5555566dba20) at hw/display/qxl-render.c:183
> qxl = 0x5555566dba20
> #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c20) at
> async.c:81
> bh = 0x5555566a4770
> bhp = 0x7ffff77bfe86
> next = 0x5555566a3c00
> ret = 1
> #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c20,
> blocking=false) at aio-posix.c:188
> node = 0x7ffff73269a4
> ret = 32767
> progress = false
> #14 0x00005555555f5747 in aio_ctx_dispatch
> (source=0x5555562f1c20, callback=0, user_data=0x0) at async.c:205
> ctx = 0x5555562f1c20
> __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
> #15 0x00007ffff730c355 in g_main_context_dispatch () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> No symbol table info available.
> #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
> context = 0x5555562f27c0
> pfds = 0x5555566da480
> #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0)
> at main-loop.c:235
> ret = 2
> spin_counter = 1
> #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
> main-loop.c:484
> ret = 21845
> timeout = 4294967295
> timeout_ns = 29767176
> #19 0x000055555587fe0c in main_loop () at vl.c:2051
> nonblocking = false
> last_io = 1
> #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfd8,
> envp=0x7fffffffe1e0) at vl.c:4507
> ---Type <return> to continue, or q <return> to quit---
> i = 64
> snapshot = 0
> linux_boot = 0
> icount_option = 0x0
> initrd_filename = 0x0
> kernel_filename = 0x0
> kernel_cmdline = 0x555555a22304 ""
> boot_order = 0x5555562ef840 "dc"
> ds = 0x5555565f64b0
> cyls = 0
> heads = 0
> secs = 0
> translation = 0
> hda_opts = 0x0
> opts = 0x5555562ef790
> machine_opts = 0x5555562f13f0
> olist = 0x555555e08220
> optind = 64
> optarg = 0x7fffffffe92d
> "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
> loadvm = 0x0
> machine_class = 0x5555562e8540
> machine = 0x555555e0de80
> cpu_model = 0x0
> vga_model = 0x0
> qtest_chrdev = 0x0
> qtest_log = 0x0
> pid_file = 0x0
> incoming = 0x0
> show_vnc_port = 0
> defconfig = true
> userconfig = true
> log_mask = 0x0
> log_file = 0x0
> mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
> realloc = 0x5555558836f6 <realloc_and_trace>,
> free = 0x55555588375d <free_and_trace>, calloc = 0,
> try_malloc = 0, try_realloc = 0}
> trace_events = 0x0
> trace_file = 0x0
> ---Type <return> to continue, or q <return> to quit---
> __func__ = "main"
> args = {machine = 0x555555e0de80, ram_size =
> 4160749568, boot_order = 0x5555562ef840 "dc",
> kernel_filename = 0x0, kernel_cmdline = 0x555555a22304 "",
> initrd_filename = 0x0, cpu_model = 0x0}
>
Thanks for the full backtrace.
I added qemu-devel and spice-devel as cc.
Can someone take a look at this backtrace of qemu crash on windows 7
resolution change when connect with spice and help to solve it please?
Some other details are in previous mails below.
Thanks for any reply.
> ------------------------------------------------------------------------
> Best Regards
>
> *From:* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>
> *Date:* 2014-07-17 16:52
> *To:* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>;
> xen-devel <mailto:xen-devel at lists.xen.org>
> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5 unstable
> Il 17/07/2014 03:48, kevin.zhang at octlink.com ha scritto:
>> Hi Fabio Fantoni,
>> I finally got it. If that's not enough, I will provide more as u
>> guide.
>> I adjust the time to just after xl create and can get stack info
>> as follow :
>>
>> (gdb) target remote localhost:1234
>> Remote debugging using localhost:1234
>> Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging
>> symbols found)...done.
>> Loaded symbols for /lib64/ld-linux-x86-64.so.2
>> 0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
>> (gdb) c
>> Continuing.
>> Program received signal SIGABRT, Aborted.
>> 0x00007ffff2e04475 in raise () from /lib/x86_64-linux-gnu/libc.so.6
>> (gdb) bt full
>> #0 0x00007ffff2e04475 in raise () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> No symbol table info available.
>> #1 0x00007ffff2e076f0 in abort () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> No symbol table info available.
>> #2 0x00007ffff2e3f52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> No symbol table info available.
>> #3 0x00007ffff2e48d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> No symbol table info available.
>> #4 0x00007ffff2e4db1c in free () from
>> /lib/x86_64-linux-gnu/libc.so.6
>> No symbol table info available.
>> #5 0x00007ffff3b5b44b in ?? () from
>> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>> No symbol table info available.
>> #6 0x00007ffff3b5b399 in pixman_image_unref () from
>> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
>> No symbol table info available.
>> #7 0x000055555585283b in qemu_pixman_image_unref
>> (image=0x555558cd1170) at ui/qemu-pixman.c:80
>> No locals.
>> #8 0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2cbc048,
>> surface=0x5555563263c0) at ui/vnc.c:588
>> vd = 0x7fffe2cbc010
>> vs = 0xff000000180420
>> #9 0x000055555584be81 in dpy_gfx_replace_surface
>> (con=0x5555566a2550, surface=0x5555563263c0) at ui/console.c:1404
>> s = 0x555556715b90
>> old_surface = 0x5555566e01e0
>> dcl = 0x7fffe2cbc048
>> #10 0x00005555556ecd52 in qxl_render_update_area_unlocked
>> (qxl=0x555556715bc0) at hw/display/qxl-render.c:131
>> vga = 0x5555567166b0
>> surface = 0x5555563263c0
>> i = 0
>> #11 0x00005555556ed021 in qxl_render_update_area_bh
>> (opaque=0x555556715bc0) at hw/display/qxl-render.c:183
>> qxl = 0x555556715bc0
>> #12 0x00005555555f5330 in aio_bh_poll (ctx=0x5555562f1c30) at
>> async.c:81
>> bh = 0x5555565fb700
>> bhp = 0x7ffff77bfe86
>> next = 0x5555566afd00
>> ret = 1
>> #13 0x00005555555f4f89 in aio_poll (ctx=0x5555562f1c30,
>> blocking=false) at aio-posix.c:188
>> node = 0x7ffff73269a4
>> ret = 32767
>> ---Type <return> to continue, or q <return> to quit---
>> progress = false
>> #14 0x00005555555f5747 in aio_ctx_dispatch
>> (source=0x5555562f1c30, callback=0, user_data=0x0) at async.c:205
>> ctx = 0x5555562f1c30
>> __PRETTY_FUNCTION__ = "aio_ctx_dispatch"
>> #15 0x00007ffff730c355 in g_main_context_dispatch () from
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>> No symbol table info available.
>> #16 0x00005555557d41ce in glib_pollfds_poll () at main-loop.c:190
>> context = 0x5555562f27c0
>> pfds = 0x5555566f75c0
>> #17 0x00005555557d42ce in os_host_main_loop_wait (timeout=0) at
>> main-loop.c:235
>> ret = 1
>> spin_counter = 1
>> #18 0x00005555557d43a1 in main_loop_wait (nonblocking=0) at
>> main-loop.c:484
>> ret = 21845
>> timeout = 4294967295
>> timeout_ns = 17515866
>> #19 0x000055555587fe0c in main_loop () at vl.c:2051
>> nonblocking = false
>> last_io = 0
>> #20 0x00005555558877e6 in main (argc=64, argv=0x7fffffffdfb8,
>> envp=0x7fffffffe1c0) at vl.c:4507
>> i = 64
>> snapshot = 0
>> linux_boot = 0
>> icount_option = 0x0
>> initrd_filename = 0x0
>> kernel_filename = 0x0
>> kernel_cmdline = 0x555555a22304 ""
>> boot_order = 0x5555562ef840 "dc"
>> ds = 0x555556715b90
>> cyls = 0
>> heads = 0
>> secs = 0
>> translation = 0
>> hda_opts = 0x0
>> opts = 0x5555562ef790
>> machine_opts = 0x5555562f13f0
>> olist = 0x555555e08220
>> ---Type <return> to continue, or q <return> to quit---
>> optind = 64
>> optarg = 0x7fffffffe915
>> "if=ide,index=1,media=cdrom,cache=writeback,id=ide-832"
>> loadvm = 0x0
>> machine_class = 0x5555562e8540
>> machine = 0x555555e0de80
>> cpu_model = 0x0
>> vga_model = 0x0
>> qtest_chrdev = 0x0
>> qtest_log = 0x0
>> pid_file = 0x0
>> incoming = 0x0
>> show_vnc_port = 0
>> defconfig = true
>> userconfig = true
>> log_mask = 0x0
>> log_file = 0x0
>> mem_trace = {malloc = 0x55555588369e <malloc_and_trace>,
>> realloc = 0x5555558836f6 <realloc_and_trace>,
>> free = 0x55555588375d <free_and_trace>, calloc = 0,
>> try_malloc = 0, try_realloc = 0}
>> trace_events = 0x0
>> trace_file = 0x0
>> __func__ = "main"
>> args = {machine = 0x555555e0de80, ram_size = 4160749568,
>> boot_order = 0x5555562ef840 "dc",
>> kernel_filename = 0x0, kernel_cmdline = 0x555555a22304
>> "", initrd_filename = 0x0, cpu_model = 0x0}
>>
>
> In your test vnc is still enabled, right? Can you try disabling vnc
> (vnc=0 in domU's xl cfg)?
> Install also these packages for missed symbols: libc6-dbg
> libpixman-1-0-dbg
>
> Thanks for any reply.
>
>> ------------------------------------------------------------------------
>> Best Regards
>>
>> *发件人：* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>
>> *发送时间：* 2014-07-16 17:03
>> *收件人：* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>;
>> xen-devel <mailto:xen-devel at lists.xen.org>
>> *主题：* Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>> 4.5 unstable
>> Il 16/07/2014 09:04, kevin.zhang at octlink.com ha scritto:
>>> Hi Fabio Fantoni,
>>> Thank you for your advice for building xen unstable.
>>> Because I have to use debian wheezy as production distro, I've
>>> got to do the test in it.
>>> Today, I edit Config.mk and write:
>>> QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git
>>> QEMU_UPSTREAM_REVISION = master
>>> Then, the built qemu-xen binary works well. Therefore, I guess
>>> that git://xenbits.xen.org/qemu-upstream-unstable.git has some very
>>> little difference
>>> compared to qemu.git. Maybe your environment cannot repeat that
>>> problem either, I'd like to provide any useful information to
>>> resolve this problem.
>>
>> I also use wheezy for both production and develop/testing.
>> I tried now on my latest testing build, of some days ago xen from
>> rebase/m2r-staging branch and qemu mainline with same Config.mk
>> before build.
>> On windows 7 pro 64 bit domUs with latest spice guest tools auto and
>> manual resolution change works without problem.
>> I'm still unable to reproduce your qemu crash.
>>
>> You can retry to catch and post backtrace with my latest better explain?
>>
>>> I know, I already posted the solution but I try to explain better.
>>>
>>> # after xl create with (qemu gdb), do it fast after xl create when
>>> arrive on qemu process launch (before timeout or xl create will fails)
>>> target remote localhost:1234 # prepare this command in other ssh to
>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>> c # press immediatly
>>> bt full # when qemu stops
>>>
>>> Sorry for my bad english.
>>
>>
>>> ------------------------------------------------------------------------
>>> Best Regards
>>>
>>> *From:* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>
>>> *Date:* 2014-07-15 16:09
>>> *To:* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>;
>>> xen-devel <mailto:xen-devel at lists.xen.org>
>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>> unstable
>>> Il 15/07/2014 07:53, kevin.zhang at octlink.com ha scritto:
>>>> Hi Fabio Fantoni,
>>>> Today I tried to use wheezy backports version of
>>>> spice-server, the problem persists with qemu-xen binary, while my
>>>> self compiled qemu 2.0 works well.
>>>> I think it is a problem and can be repeated.
>>>> Then, I will summarize my compilation process here:
>>>> Firstly install debian wheezy 7.5 amd64 and necessary build
>>>> dependency. Then:
>>>>
>>>> 1. git clone git://xenbits.xen.org/xen.git
>>>> <http://xenbits.xen.org/gitweb/?p=xen.git>
>>>> 2. install backport version libspice-server-dev
>>>> libspice-protocol-dev
>>>>
>>>> root at debian:~# apt-cache policy libspice-server-dev
>>>> libspice-protocol-dev
>>>> libspice-server-dev:
>>>> Installed: 0.12.4-0nocelt2~bpo70+1
>>>> Candidate: 0.12.4-0nocelt2~bpo70+1
>>>> Version table:
>>>> *** 0.12.4-0nocelt2~bpo70+1 0
>>>> 100 http://cdn.debian.net/debian/
>>>> wheezy-backports/main amd64 Packages
>>>> 100 /var/lib/dpkg/status
>>>> libspice-protocol-dev:
>>>> Installed: 0.12.6-1~bpo70+2
>>>> Candidate: 0.12.6-1~bpo70+2
>>>> Version table:
>>>> *** 0.12.6-1~bpo70+2 0
>>>> 100 http://cdn.debian.net/debian/
>>>> wheezy-backports/main amd64 Packages
>>>> 100 /var/lib/dpkg/status
>>>>
>>>> 3. patch for QXL option
>>>> 4. ./configure --prefix=/usr
>>>> 5. add spice and usb-redir option for qemu-xen-upstream
>>>> 6. make xen;make tools;make install-xen;make install-tools
>>>>
>>>> To compile qemu 2.0 from qemu.org:
>>>> 1. wget http://wiki.qemu-project.org/download/qemu-2.0.0.tar.bz2
>>>> 2. ./configure --enable-xen --target-list=i386-softmmu
>>>> --extra-cflags="-I/usr/src/xen/tools/include
>>>> -I/usr/src/xen/tools/libxc -I/usr/src/xen/tools/xenstore" \
>>>> --enable-spice --enable-usb-redir
>>>> 3 .make;make install
>>>
>>> For fast unstable tests I do this (using my github rebase/m2r-*):
>>> Install of opus, usbredir and libusbx from backports.
>>> Rebuild and install new seabios 1.7.5-1 and spice packages (server
>>> 0.12.5-1 and protocol 0.12.7-1) from sid that contains many fixes
>>> (simply and fast with git clone of debian repository and debuild).
>>> ./configure --prefix=/usr --enable-qemu-traditional=no
>>> --with-system-seabios=/usr/share/seabios/bios-256k.bin
>>> --with-extra-qemuu-configure-args="--enable-spice --enable-usb-redir"
>>> make debball
>>> dpkg -i of xen package in dist (contain both xen and qemu)
>>> And if I need to test newer qemu in development I simply change the
>>> qemu git with mainline in Config.mk.
>>>
>>> And for newer production servers I start prepared new xen's debian
>>> packages awaiting debian maintainers replies:
>>> https://github.com/Fantu/pkg-xen/tree/wheezy-backports
>>> Needs also qemu rebuild to use new xen 4.4 libraries (simply and
>>> fast with git clone of debian repository and debuild).
>>>
>>> There is also a problem of jpeg-turbo in debian and for have better
>>> performances and not too many cpu waste I for now solved with:
>>> apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
>>> vi /etc/apt/sources.list.d/x2go.list
>>> # X2Go Repository (for jpeg-turbo as default and with full -dev package)
>>> deb http://packages.x2go.org/debian wheezy heuler
>>> deb-src http://packages.x2go.org/debian wheezy heuler
>>> aptitude update
>>> aptitude install x2go-keyring && aptitude update
>>> aptitude install libjpeg8-turbo-dev
>>>
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *发件人：* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>
>>>> *发送时间：* 2014-07-14 16:49
>>>> *收件人：* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>; xen-devel
>>>> <mailto:xen-devel at lists.xen.org>
>>>> *主题：* 回复: Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen
>>>> 4.5 unstable
>>>> Hi Fabio Fantoni,
>>>> Thank you for your reply.
>>>> It is really weird.
>>>> I compiled both qemu binary ( qemu-upstream in xen and
>>>> qemu-2.0 from qemu.org website) in the same environment,
>>>> the binary in xen has the problem while
>>>> the other one works well.
>>>> I will check whether wheezy backport has libspice-server-dev
>>>> and libspice-protocol-dev and try again.
>>>> ------------------------------------------------------------------------
>>>> Best Regards
>>>>
>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>
>>>> *Date:* 2014-07-14 15:59
>>>> *To:* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>;
>>>> xen-devel <mailto:xen-devel at lists.xen.org>
>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>> unstable
>>>> Il 14/07/2014 07:29, kevin.zhang at octlink.com ha scritto:
>>>>> Hi Fabio Fantoni,
>>>>> Today, I've done another test on xenbits xen 4.5 unstable.
>>>>> This time, I directly compiled xen on my test server, and use
>>>>> default libspice-server-dev and libspice-protocol-dev header
>>>>> files for spice option.
>>>>>
>>>>> root at debian:~# apt-cache policy libspice-server-dev
>>>>> libspice-protocol-dev
>>>>> libspice-server-dev:
>>>>> Installed: 0.11.0-1+deb7u1
>>>>> Candidate: 0.11.0-1+deb7u1
>>>>> Version table:
>>>>> *** 0.11.0-1+deb7u1 0
>>>>> 500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>> 100 /var/lib/dpkg/status
>>>>> libspice-protocol-dev:
>>>>> Installed: 0.10.1-1
>>>>> Candidate: 0.10.1-1
>>>>> Version table:
>>>>> *** 0.10.1-1 0
>>>>> 500 http://cdn.debian.net/debian/ wheezy/main amd64 Packages
>>>>> 100 /var/lib/dpkg/status
>>>>>
>>>>> I also download qemu-2.0 source code from qemu.org, and
>>>>> compiled it by the way mentioned in
>>>>> http://wiki.xen.org/wiki/QEMU_Upstream.
>>>>> Then I create win7 hvm with qemu-xen and
>>>>> /usr/local/bin/qemu-system-i386 respectively.
>>>>> The result shows that:
>>>>> 1 . qemu-upstream used in xen 4.5 unstable still exited when
>>>>> changing screen resolution,
>>>>> 2. my self-compiled qemu2.0 behave normally.
>>>>> I think maybe there's still some differences between the two
>>>>> qemu repository.
>>>>
>>>> Use spice from backports or recompile the latest from Sid, wheezy
>>>> packages are too old for newer qemu.
>>>> xen already download and compile qemu upstream automatically if you
>>>> not specify binary in repository.
>>>> I also use use wheezy dom0 with same xen and qemu and same domU and
>>>> spice guest tools installed automatically resize the windows
>>>> resolution without problem (except rare cases when I connect
>>>> remote-viewer before windows start).
>>>> Below also reply to other mail.
>>>>
>>>>> I'm actively waiting for your advice and willing to do the
>>>>> following debug.
>>>>> vm config file is as follow:
>>>>>
>>>>> name='Win7'
>>>>> builder="hvm"
>>>>> memory=2048
>>>>> vcpus=2
>>>>> vif=['bridge=br0']
>>>>> disk=['/srv/vm_templates/1.qcow2,qcow2,hda,rw',',raw,hdb,ro,cdrom']
>>>>> boot='dc'
>>>>> device_model_version="qemu-xen"
>>>>> #device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>> #device_model_override="/usr/local/bin/qemu-system-i386"
>>>>> viridian=1
>>>>> vnc=1
>>>>> vnclisten="0.0.0.0"
>>>>> on_crash="destroy"
>>>>> vga="qxl"
>>>>> spice=1
>>>>> spicehost='0.0.0.0'
>>>>> spiceport=6000
>>>>> spicedisable_ticketing=1
>>>>> spicevdagent=1
>>>>> spice_clipboard_sharing=1
>>>>> spiceusbredirection=4
>>>>> soundhw="hda"
>>>>> localtime=1
>>>>> videoram=128
>>>>>
>>>>
>>>> videoram=128 is not needed with qxl as already the default.
>>>> Try to disable vnc when you use spice, even if I used with also vnc
>>>> many times without problem time ago.
>>>>
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *From:* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>
>>>>> *Date:* 2014-07-14 10:26
>>>>> *To:* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>; xen-devel
>>>>> <mailto:xen-devel at lists.xen.org>
>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>> unstable
>>>>> Hi Fabio Fantoni,
>>>>> Thank you for your help.
>>>>> If I use your method to run qemu-gdb when using xl create, xl
>>>>> will complain startup timeout.
>>>>
>>>> I know, I already posted the solution but I try to explain better.
>>>>
>>>> # after xl create with (qemu gdb), do it fast after xl create when
>>>> arrive on qemu process launch (before timeout or xl create will fails)
>>>> target remote localhost:1234 # prepare this command in other ssh to
>>>> the xen dom0 and enter on xl create when arrive on qemu launch
>>>> c # press immediatly
>>>> bt full # when qemu stops
>>>>
>>>> Sorry for my bad english.
>>>>
>>>>> Perhaps I did not describe my problem clearly enough, I can
>>>>> successfully create windows HVM, my problem happened when I change
>>>>> windows screen resolution.
>>>>> The qemu process suddenly exited while xl list can still list the
>>>>> domU information.
>>>>> I am using debian wheezy 7.5 amd 64, I am using fantu's xen
>>>>> 4.5 unstable and the qemu-xen-remote in his code repository,
>>>>>
>>>>> root at debian:~# /usr/lib/xen/bin/qemu-system-i386 -version
>>>>> QEMU emulator version 2.0.0, Copyright (c) 2003-2008 Fabrice
>>>>> Bellard
>>>>>
>>>>> And I compiled Xen from fantu's xen repository in compilation
>>>>> server, then use install.sh in dist dir to install xen packages in
>>>>> my test server.
>>>>> My compilation server has spice 0.12.4 compiled and installed.
>>>>> My test server has debian wheezy backport qemu installed with
>>>>> spice-server:
>>>>>
>>>>> dpkg -l |grep spice
>>>>> ii libspice-server1:amd64 0.12.4-0nocelt2~bpo70+1
>>>>>
>>>>> Then how can I obtain useful debug information after qemu exit
>>>>> with vm running?
>>>>> ------------------------------------------------------------------------
>>>>> Best Regards
>>>>>
>>>>> *From:* Fabio Fantoni <mailto:fabio.fantoni at m2r.biz>
>>>>> *Date:* 2014-07-11 18:06
>>>>> *To:* kevin.zhang at octlink.com <mailto:kevin.zhang at octlink.com>;
>>>>> xen-devel <mailto:xen-devel at lists.xen.org>
>>>>> *Subject:* Re: [Xen-devel] QXL problem: Xen 4.4.1 rc1 and xen 4.5
>>>>> unstable
>>>>> Il 11/07/2014 04:38, kevin.zhang at octlink.com ha scritto:
>>>>>> Hi all,
>>>>>> Firstly please forgive me if I put this problem in the wrong mail
>>>>>> list.
>>>>>> However, it seems that xen-users mail list cannot resolve this
>>>>>> QXL problems. Therefore, I have to post QXL problem in devel mail
>>>>>> list.
>>>>>> My problem is as follow:
>>>>>> I'm testing QXL for windows HVM, spice works well with stdvga.
>>>>>> However, when I switch to QXL, qemu exit abnormally:
>>>>>> I specify vga="qxl" and videoram=128, using qemu-xen. The windows
>>>>>> 7 boots and automatially switch resolution for me in virt-viewer.
>>>>>> While display and sound transfering very well, if I change
>>>>>> display resolution, the virt-viewer will be suddenly closed and
>>>>>> I check the physical server, the qemu process disappear
>>>>>> simultaneously.
>>>>>> Then I switch to wheezy backport qemu 2.0 as device model, the
>>>>>> qemu process will exit as soon as the welcome page appears and at
>>>>>> the beginning of resolution change.
>>>>>> I tested and found the same bug on both xenbits xen 4.4.1 rc1 and
>>>>>> Fantu's Xen 4.5 unstable, this problem exists in both branches.
>>>>>> Is it a known issue or is there any solution for this bug?
>>>>>> Thank you very much!
>>>>>
>>>>> Thanks for testing spice and qxl and report issue.
>>>>> I have spice + qxl working as kvm on xen unstable except this problem:
>>>>> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01021.html
>>>>>
>>>>> Please post details on your dom0 installation and domU (for
>>>>> example xl cfg,
>>>>> spice guest tools version ecc...)
>>>>> About qemu crash try to take a full backtrace with gdb and post it
>>>>> here.
>>>>>
>>>>> Small help with gdb of qemu launched by xl:
>>>>>
>>>>> Add the line below in domU's xl cfg:
>>>>> device_model_override="/usr/lib/xen/bin/qemu-gdb"
>>>>>
>>>>> vi /usr/lib/xen/bin/qemu-gdb # create the file, change the qemu
>>>>> path if
>>>>> needed
>>>>> #!/bin/sh
>>>>> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386 "$@"
>>>>>
>>>>> # after xl create, do it fast (before timeout or xl create will fails)
>>>>> target remote localhost:1234
>>>>> c
>>>>> bt full # when qemu stops
>>>>>
>>>>> You should install also all needed dbg packages before, spice qemu
>>>>> ecc or
>>>>> without package should be compiled with debug enabled (for xen and
>>>>> qemu
>>>>> default in unstable).
>>>>>
>>>>> The latest qemu crash with spice I saw was in 2.0-rc solved before
>>>>> 2.0.0
>>>>> final, your qemu is at least 2.0.0 final?
>>>>> http://git.qemu.org/?p=qemu.git;a=commit;h=dc491cfc14074064ed54a872b62cce6ca1330644
>>>>>
>>>>>> Kevin
>>>>>> Best Regards,
>>>>>>
>>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20140718/02660989/attachment-0001.html>
More information about the Spice-devel
mailing list