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.
发送时间： 2014-07-16 17:03
主题： Re:回复: Re: [Xen-devel] QXL problem: Xen 4.4.1
rc1 and xen 4.5 unstable
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.
Date: 2014-07-15 16:09
Subject: Re: [Xen-devel] QXL problem: Xen
4.4.1 rc1 and xen 4.5 unstable
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:
2. install backport
version libspice-server-dev libspice-protocol-dev
root@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
/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
/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:
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
发送时间： 2014-07-14 16:49
主题： 回复: 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.
Date: 2014-07-14 15:59
Subject: Re: [Xen-devel] QXL
problem: Xen 4.4.1 rc1 and xen 4.5 unstable
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@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
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
100
/var/lib/dpkg/status
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"
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.
Date: 2014-07-14 10:26
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@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?
Date: 2014-07-11 18:06
Subject: Re: [Xen-devel]
QXL problem: Xen 4.4.1 rc1 and xen
4.5 unstable
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
Best Regards,
|
