Re: [Qemu-devel] Serial: possible hang during intensive interaction over the console

[Andrey Korolyov]

On Thu, Sep 4, 2014 at 8:03 PM, Andrey Korolyov <address@hidden> wrote:
> On Thu, Sep 4, 2014 at 5:33 PM, Kirill Batuzov <address@hidden> 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.