[Spice-devel] qemu crash on windows 7 resolution change on spice
Fabio Fantoni
fabio.fantoni at m2r.biz
Mon Jul 28 07:33:10 PDT 2014
Il 18/07/2014 09:55, Fabio Fantoni ha scritto:
> 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.
@Kevin, can you post the output of xl -vvv create please?
Looking backtrace seems still using something about vnc and is strange
if you disabled it from domU's xl cfg:
> #8 0x000055555587446b in vnc_dpy_switch (dcl=0x7fffe2c99048,
> surface=0x7fffd40b7c10) at ui/vnc.c:588
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/20140728/33084112/attachment-0001.html>
More information about the Spice-devel
mailing list