On Sun, Oct 02, 2011 at 03:38:29PM -0400, Avi Kivity wrote: > > > > > > > Well, any messages? > > > > None I can find. I'll try again later today and double check. > > > Please do. Oct 2 19:53:01 vrici dbus: [system] Activating service name='net.reactivated.Fprint' (using servicehelper) Oct 2 19:53:01 vrici dbus: [system] Successfully activated service 'net.reactivated.Fprint' Oct 2 19:53:55 vrici kernel: [155001.460802] device eth0 entered promiscuous mode Oct 2 19:53:56 vrici kernel: [155002.367313] device eth0 left promiscuous mode type=SYSCALL msg=audit(10/02/2011 19:53:14.731:48050) : arch=x86_64 syscall=execve success=yes exit=0 a0=7fff41959fd0 a1=7fc2f48d5150 a2=1474800 a3=6a6222 items=3 ppid=18453 pid=18456 auid=rlpowell uid=rlpowell gid=rlpowell euid=rlpowell suid=rlpowell fsuid=rlpowell egid=rlpowell sgid=rlpowell fsgid=rlpowell tty=pts0 ses=4 comm=date exe=/bin/date subj=staff_u:staff_r:staff_t:s0 key=64bit_execs ---- type=SYSCALL msg=audit(10/02/2011 19:53:56.454:48059) : arch=x86_64 syscall=close success=yes exit=0 a0=3 a1=0 a2=1c11220 a3=7fff2eb675b0 items=0 ppid=18457 pid=18458 auid=rlpowell uid=tcpdump gid=tcpdump euid=tcpdump suid=tcpdump fsuid=tcpdump egid=tcpdump sgid=tcpdump fsgid=tcpdump tty=pts0 ses=4 comm=tcpdump exe=/usr/sbin/tcpdump subj=staff_u:unconfined_r:unconfined_t:s0 key=(null) type=ANOM_PROMISCUOUS msg=audit(10/02/2011 19:53:56.454:48059) : dev=eth0 prom=no old_prom=yes auid=rlpowell uid=tcpdump gid=tcpdump ses=4 That's all I could find that's even remotely interesting. > > > 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. If it was the *host*, I wouldn't be complaining on the KVM list, though, I'd be complaining on the main kernel list. :) 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. > > 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 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 2393.999 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes 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 bogomips : 4787.99 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 2393.999 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes 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 bogomips : 4787.78 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: > 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 -Robin -- 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
