On 20.08.2012 10:01, Mike Gerber wrote:
> Package: qemu-kvm
> Version: 1.1.0+dfsg-3
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> 
> I currently run 3 VMs using libvirt/qemu-kvm. Two of them are mostly idle and
> stable, but the third one locks up within 1 or 2 days. This third VM
> uses an emulated ES1370 sound card (host has an ASUS Xonar DX sound card),
> to stream host audio input to an icecast server using darkice.

Does this also happen without ES1370 device?  Do other guests use this
device too?  How active the audio/sound usage is?

It is vital to understand where the problem is as close as possible, since
it isn't easy to reproduce the problem, and you apparently pointed out one
difference (ES1370) which might be the root of the issue, but might be not.

> The hanging kvm process uses 100% CPU, there's no serial console anymore, no 
> access to VNC anymore. No output on netconsole either. Unfortunately, I cannot
> even get a useful gdb backtrace:
> 
>   # gdb
>   GNU gdb (GDB) 7.4.1-debian
>   Copyright (C) 2012 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
>   This is free software: you are free to change and redistribute it.
>   There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>   and "show warranty" for details.
>   This GDB was configured as "x86_64-linux-gnu".
>   For bug reporting instructions, please see:
>   <http://www.gnu.org/software/gdb/bugs/>.
>   (gdb) attach 3259
>   Attaching to process 3259
>   Reading symbols from /usr/bin/kvm...Reading symbols from 
> /usr/lib/debug/usr/bin/kvm...done.
>   Unable to read JIT descriptor from remote memory!
>   (gdb) info threads
>     Id   Target Id         FrameĀ·
>     * 1    process 3259 "kvm" 0x00007f32ebb20f7b in ?? ()
>     (gdb) thread apply all bt full
> 
>     Thread 1 (process 3259):
>     #0  0x00007f32ebb20f7b in ?? ()
>     No symbol table info available.

You can try installing qemu-kvm-gdb to get symbol table.
That might be useful.  If that wont help, it'll mean we
have a bug in qemu-kvm package at providing debugging
info.

> No useful strace output either:
> 
>   # strace -ff -p3259
>   Process 3259 attached with 2 threads - interrupt to quit
>   [pid  3270] futex(0x7f32ec94ea80, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished 
> ...>
>   Process 3259 detached
>   Process 3270 detached

Hmm.  And that's all?  In that case it'd be very nice really
to have a backtrace.

> Both the guest and the host use this kernel:
> 
>   Linux version 3.2.0-3-amd64 (Debian 3.2.23-1) 
> (debian-ker...@lists.debian.org)
>   (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 SMP Mon Jul 23 02:45:17 UTC 2012
> 
> kvm command line (run by libvirt):
> 
>   105       3259 61.3 27.2 1540272 1071712 ?     RLl  Aug18 1331:39 
> /usr/bin/kvm
>   -S -M pc-1.1 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name 
> mp3
>   -uuid 25d2b76c-9533-c55a-b5e2-07da213886f1 -nodefconfig -nodefaults -chardev
>   socket,id=charmonitor,path=/var/lib/libvirt/qemu/mp3.monitor,server,nowait 
> -mon
>   chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
> -device
>   piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
>   file=/dev/vg_vms/lv_mp3,if=none,id=drive-virtio-disk0,format=raw -device
>   
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-di
>   -netdev tap,fd=20,id=hostnet0 -device
>   
> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:b1:e7:80,bus=pci.0,addr=0x3
>   -chardev pty,id=charserial0 -device 
> isa-serial,chardev=charserial0,id=serial0
>   -vnc 127.0.0.1:2 -vga cirrus -device ES1370,id=sound0,bus=pci.0,addr=0x6 
> -device
>   i6300esb,id=watchdog0,bus=pci.0,addr=0x7 -watchdog-action reset -device
>   virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4

That's nothing fancy/unusual.

> I tried running with clocksource=acpi_pm inside the VM, or without VNC, all
> the same: Hung kvm within 1 or 2 days.

> Any help on how to track this down - for example how to make gdb output
> useful - would be appreciated!

As for gdb - see above.  Meanwhile I'll try to see if debugging generally
works.

Also, there's a new version (prerelease - I sent an unblock request to the
release team about it) available at my site --
  http://www.corpit.ru/mjt/tmp/qemu-kvm/ ,
in particular,
 http://www.corpit.ru/mjt/tmp/qemu-kvm/qemu-kvm_1.1.1+dfsg-1_amd64.deb
(it is all signed with my regular debian gpg key if you're concerned).
Can you please try this version too?  It contains many bugfixes in all
areas, and there's some (albiet small) chance this issue is already
fixed.

What activity your guest performs?  Maybe I can try to reproduce your
issue locally, you provided almost all information needed for this
except of some mention of the workload.

Thank you for a good bugreport!

/mjt


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to