Hi Michael, * Michael Tokarev schrieb: > On 20.08.2012 10:01, Mike Gerber wrote: > > 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 VM would be useless without the ES1370, as I am using it to stream audio to an icecast server on the same VM (see above.) I *could* test without the sound device but I doubt that would be useful. On the other hand, the other VMs don't have any load yet (still a test setup.) Audio usage is almost full time (stream is on about 50% of the time), for two MP3 encoded streams (one high, one low quality.) > > (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. It's already installed (Reading symbols from /usr/lib/debug/usr/bin/kvm...done.), so that might be a bug with the debugging info - or with my use of gdb. > > > 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. Yep, that's all. I left it running for about a minute and that is all output, until I hit ^C. > > 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. Also, the problem happens without the watchdog, too. > As for gdb - see above. Meanwhile I'll try to see if debugging generally > works. Please check it, maybe I'm doing something wrong. > 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. I'm running it now. It will take some time to see if there's any improvement, as it took one or two days until the bug occured. > 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. Oh, you must have overseen it? It streams audio using darkice (darkice-full from deb-multimedia.org for MP3 support, to be precise) and archiving the stream. About 50% CPU (on one CPU) usually. The system is not in production use yet, so there's no significant network load, just the darkice talking to the icecast2 on the same VM. Initially I had planned to use the host sound card using PCI passthrough, but then I found out that the machine doesn't have an IOMMU... So I suspect that the bug is somewhere in the sound emulation. The host is running CPU freq governor=ondemand, might that be a problem? > Thank you for a good bugreport! I do my best :-) Thanks for your time. Cheers, Mike -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
