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-disk2,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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
