Re: [Xen-devel] [Qemu-devel] Qemu 2.0 regression with xen: qemu crash on any domUs S.O. start

[Laszlo Ersek <lersek@xxxxxxxxxx>]

On 04/02/14 13:13, Fabio Fantoni wrote:
> Il 01/04/2014 18:24, Laszlo Ersek ha scritto:
>> On 04/01/14 17:01, Fabio Fantoni wrote:
>>> Today I tried latest qemu 2.0 compiled from git (commit
>>> 63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
>>> Debian 7 (Wheezy) 64 bit with kernel from package
>>> linux-image-3.2.0-4-amd64 version 3.2.54-2 and all dependency packages
>>> for xen, spice and usb redirection.
>>> Seabios 1.7.3-3, spice 0.12.4-0nocelt2 and usbredir 0.6-2 compiled from
>>> debian unstable sources.
>>> The xen-unstable upstream commit is
>>> 4787f667bcee205c56a27da59b766a53e1e929eb, plus these patches not
>>> upstream:
>>> tools: various things just to build test
>>> tools: Improve make debball
>>> libxl: Add qxl vga interface support for upstream qemu
>>> libxl: add basic spice support for pv domUs
>>>
>>> Qemu crashes always on domU S.O. start, on both pv and hvm domUs.

I may have misunderstood you (hence my gdb suggestion may not have been
appropriate) -- does the guest kernel crash *in* qemu, or does the qemu
host-side process crash? I understood your message to imply the latter.

>>>
>>> Same dom0 with qemu 1.6 from xen-unstable repository used for some tests
>>> yesterday and was full working.
>>> I also update seabios to 1.7.4-4 compiled from debian unstable sources
>>> but the problem persists.
>>>
>>> I looked on dom0 logs, qemu logs and xl dmesg and I found only a qemu
>>> segfault related on each domU in dom0 syslog, for example the latest:
>>> [  844.273170] qemu-system-i38[3545]: segfault at 8 ip 00007fa905dcc4c1
>>> sp 00007fff41220810 error 4 in qemu-system-i386[7fa905ad5000+598000]

Can you reproduce this qemu process SIGSEGV while running qemu in
(host-)gdb? Or else, can you save a coredump and look into it with gdb?

The steps you describe with gdbserver target the guest OS as debuggee. I
suggested that the host side qemu process be debugged (because that's
what crashes).

Laszlo

>>>
>>> If you need more informations, tests and/or logs tell me and I'll post
>>> them.
>> Whoever looks into this would be greatly helped:
>> - if you bisected the issue (between 1.6 and 2.0-rcX),
> 
> I tried time ago qemu 1.7 and qemu 2.0 on start of development without
> problem on domUs start but I'll retry.
> 
>> - if you posted qemu's backtrace at the sigsegv.
> 
> I tried to use gdb following this old post:
> https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html
> but with same changes:
> 
> /usr/lib/xen/bin# vi qemu-system-i386
> #!/bin/sh
> exec gdbserver 0.0.0.0:1234 /usr/lib/xen/bin/qemu-system-i386.bak "$@"
> 
> gdb /usr/lib/xen/bin/qemu-system-i386.bak
> target remote localhost:1234
> 
> This command with gdb on qemu fails:
> xl -vvv create /etc/xen/wheezy.cfg
> ...
> libxl: error: libxl_dm.c:1378:device_model_spawn_outcome: domain 13
> device model: spawn failed (rc=-3)
> libxl: error: libxl_create.c:1207:domcreate_devmodel_started: device
> model did not start: -3
> libxl: debug: libxl_dm.c:1485:kill_device_model: Device Model signaled
> ...
> 
> the dom0 syslog show segfault also in this case and the qemu log is
> different on first lines (probably for gdbserver):
> less /var/log/xen/qemu-dm-wheezy.log
> Process /usr/lib/xen/bin/qemu-system-i386.bak created; pid = 8238
> Listening on port 1234
> Remote debugging from host 127.0.0.1
> xc: error: linux_gnttab_set_max_grants: ioctl SET_MAX_GRANTS failed (22
> = Invalid argument): Internal error
> xen be: qdisk-51712: xc_gnttab_set_max_grants failed: Invalid argument
> 
> 
> gdb on xl create show:
> (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)
> 
> (gdb) bt full
> #0  0x00007ffff7dddaf0 in ?? () from /lib64/ld-linux-x86-64.so.2
> No symbol table info available.
> #1  0x0000000000000013 in ?? ()
> No symbol table info available.
> #2  0x00007fffffffe871 in ?? ()
> No symbol table info available.
> #3  0x00007fffffffe897 in ?? ()
> No symbol table info available.
> #4  0x00007fffffffe8a2 in ?? ()
> No symbol table info available.
> #5  0x00007fffffffe8a5 in ?? ()
> No symbol table info available.
> #6  0x00007fffffffe8ae in ?? ()
> No symbol table info available.
> #7  0x00007fffffffe8ef in ?? ()
> No symbol table info available.
> #8  0x00007fffffffe8f4 in ?? ()
> No symbol table info available.
> #9  0x00007fffffffe913 in ?? ()
> No symbol table info available.
> #10 0x00007fffffffe91f in ?? ()
> No symbol table info available.
> #11 0x00007fffffffe92b in ?? ()
> No symbol table info available.
> #12 0x00007fffffffe931 in ?? ()
> ---Type <return> to continue, or q <return> to quit---
> 
> the qemu include debug and is not stripped:
> file /usr/lib/xen/bin/qemu-system-i386.bak
> /usr/lib/xen/bin/qemu-system-i386.bak: ELF 64-bit LSB shared object,
> x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.26,
> BuildID[sha1]=0x5aa043b5524d74d166ead62527343080384d586b, not stripped
> and I also tried:
> aptitude install libc6-dbg
> but same result.
> 
> I not understand what I missed for correct xl create and/or gdb
> informations.
> Can someone help me please?
> 
> Thanks for any reply
> 
>>
>> Laszlo
>>
>>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel