From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Re: [kvm] Re: [kvm] Re: [kvm] Re: [kvm] Re: [kvm] Re: tcpdump locks up kvm host for a while. Date: Tue, 04 Oct 2011 20:15:12 +0200 Message-ID: <4E8B4D30.9030304@redhat.com> References: <20111002173745.GG30948@stodi.digitalkingdom.org> <20111003030303.GH30948@stodi.digitalkingdom.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7BIT Cc: Nikola Ciprich , kvm@vger.kernel.org To: Robin Lee Powell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49623 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932853Ab1JDSPZ convert rfc822-to-8bit (ORCPT ); Tue, 4 Oct 2011 14:15:25 -0400 In-Reply-To: <20111003030303.GH30948@stodi.digitalkingdom.org> Sender: kvm-owner@vger.kernel.org List-ID: On 10/03/2011 05:03 AM, Robin Lee Powell wrote: > > > > Alternatively, detailed instructions to reproduce? > > > > > > Start a VM. Wait a few days. Run tcpdump. The system locks up > > > for 30+ seconds. > > > > How do you detect the lockup? Are you at the console when this > > happens and everything just freezes? The entire host, right, not > > guests? > > > > Is the lockup immediate after starting tcpdump? > > Ooooh. Oh, we're on the wrong page entirely. This *only* happens > on the guests. tcpdump on the master host causes no trouble of any > kind whatsoever. > > I guess I never specified that, maybe? Shame on me, if so. Well, the subject line does say "kvm host". > If it was the *host*, I wouldn't be complaining on the KVM list, > though, I'd be complaining on the main kernel list. :) Be sure to copy kvm@ too if it happens - certainly kvm bugs can affect the host. > > When I run tcpdump on a *guest*, the entire guest completely freezes > up; no response even to hitting enter on the console. "virsh list" > also locks up whenever it tries to print state about that VM (but > the others work fine), as does any other operation that touches the > state of that VM. The VM takes up 100% of CPU on one core while > this is happening. Eventually it gets better. You can use 'perf kvm' to figure out where the guest is spinning. > > > > That's all I have. There are, of course, any number of details that > > > make my VMs different from yours, but they're basically straight > > > Fedora 15. I could give arbitrary amounts of detail, but I've no > > > idea what to concentrate on. > > > > > > > host /proc/cpuinfo > > model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow constant_tsc indicates tsc should be good. > > > qemu command line > > qemu 11811 1 1 Oct01 ? 00:42:13 /usr/bin/qemu-kvm -S -M pc-0.14 -enable-kvm -m 1536 -smp 1,sockets=1,cores=1,threads=1 -name vrici -uuid 20fc34fc-438e-3f51-d53e-406a68f96cbc -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/vrici.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -boot c -drive file=/dev/mapper/local-vrici_root,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/dev/mapper/local-vrici_srv,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/mapper/local-vrici_swap,if=none,id=drive-virtio-di sk2,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=virtio-disk2 -drive file=/dev/mapper/local-vrici_home,if=none,id=drive-virtio-disk3,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x8,drive=drive-virtio-disk3,id=virtio-disk3 -netdev tap,fd=32,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:34:91:67,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:1 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 > Nothing suspicious here. -- error compiling committee.c: too many arguments to function