On Thu, Sep 4, 2014 at 8:03 PM, Andrey Korolyov <[email protected]> wrote: > On Thu, Sep 4, 2014 at 5:33 PM, Kirill Batuzov <[email protected]> wrote: >> On Thu, 4 Sep 2014, Andrey Korolyov wrote: >>> >>> Thanks, the launch string can be borrowed from attach here: >>> http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg00482.html, >>> the same VM is going under test. >>> >>> >>> By hang I mean stopping ability to send icmp replies, it is like a >>> kind of a watermark for issues I count serious after. Just tested >>> again, the ceiling is not exactly representing all available cpu quota >>> *every* time but is rounded by seemingly random count of cores from 3. >>> to 9 in mine series of tests, with quota limit of 12. VM became >>> unresponsive in matter of seconds, consumption raising by 'clicking' >>> core count for about a half of minute, stabilizing then. Guest args >>> are console=tty0 console=ttyS0,9600n8. >>> >>> >> >> I modified your command line a bit to match my environment: >> - removed block drive and related options, >> - changed network configuration from vhsot to tap, >> - changed bios to default one shipped with QEMU 2.1, >> - added parameters to run aboriginal linux. >> >> Neither of these should affect logic of serial port, yet I was not able >> to reproduce the bug again. Any ideas what am I missing? >> >> My command line looks like this: >> >> qemu-system-x86_64 -enable-kvm -name vm29180 -machine >> pc-i440fx-2.1,accel=kvm,usb=off \ >> -cpu SandyBridge,+kvm_pv_eoi -bios bios.bin -m 512 -realtime mlock=off \ >> -smp 12,sockets=1,cores=12,threads=12 -numa >> node,nodeid=0,cpus=0-11,mem=512 \ >> -uuid 9ca88d08-5b89-47f2-bfbf-926efcc500cc -nographic -no-user-config >> -nodefaults \ >> -device sga -chardev >> socket,id=charmonitor,path=vm29180.monitor,server,nowait \ >> -mon chardev=charmonitor,id=monitor,mode=control -rtc >> base=utc,driftfix=slew \ >> -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown \ >> -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot >> strict=on \ >> -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x4 \ >> -device virtio-serial-pci,id=virtio-serial0,vectors=1,bus=pci.0,addr=0x5 \ >> -chardev pty,id=charserial0 -device >> isa-serial,chardev=charserial0,id=serial0 \ >> -chardev socket,id=charchannel0,path=vm29180.sock,server,nowait \ >> -device >> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.1 >> \ >> -object iothread,id=vm29180blk0 -m 512,slots=31,maxmem=16384M \ >> -object memory-backend-ram,id=mem0,size=512M -device >> pc-dimm,id=dimm0,node=0,memdev=mem0 \ >> -object memory-backend-ram,id=mem1,size=512M -device >> pc-dimm,id=dimm1,node=0,memdev=mem1 \ >> -object memory-backend-ram,id=mem2,size=512M -device >> pc-dimm,id=dimm2,node=0,memdev=mem2 \ >> -object memory-backend-ram,id=mem3,size=512M -device >> pc-dimm,id=dimm3,node=0,memdev=mem3 \ >> -object memory-backend-ram,id=mem4,size=512M -device >> pc-dimm,id=dimm4,node=0,memdev=mem4 \ >> -object memory-backend-ram,id=mem5,size=512M -device >> pc-dimm,id=dimm5,node=0,memdev=mem5 \ >> -object memory-backend-ram,id=mem6,size=512M -device >> pc-dimm,id=dimm6,node=0,memdev=mem6 \ >> -hda hda.sqf -kernel bzImage \ >> -append "root=/dev/hda rw init=/sbin/init.sh panic=1 console=ttyS0 >> HOST=i686" \ >> -net nic,model=e1000 -net tap,ifname=tap0,script=no,downscript=no >> >> PS: I did not specify baud rate of serial console because init in my >> rootfs does not like it. From linux kernel documentation it should be >> 9600n8 by default. >> >> -- >> Kirill > > Heh, it is kernel- (defaults-) dependent after all. Debian hangs > always, on 3.10, 3.14 and 3.16, Fedora 20 works fine on 3.15. I`ll > check if there are any 82550-specific patches in Fedora tree a bit > later.
It is a setting-dependent issue, checked this. Though I am still searching which option causing such a huge difference, vast majority of distros with default kernels hanged completely during test. Stock SuSE/CentOS/Debian kernels can be used for testing.
