Hide Forgot
Description of problem: The guest was attached one pci with two ports,one is for transferring data from host to guest another is for guest to host. Version-Release number of selected component (if applicable): build virtio-win-1.6.5-5 How reproducible: 2 times Steps to Reproduce: 1.boot up guest with the guest /usr/libexec/qemu-kvm -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -name usb-device -uuid b03eea94-a502-4142-b541-96f86473a07a -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1,nr=1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port2,nr=2 -drive file=win8-32.qcow3,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial=QEMU-DISK1 -device ide-hd,bus=ide.0,unit=0,drive=drive-system-disk,id=system-disk,bootindex=2 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet0,mac=00:15:65:01:3a:20 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -vnc :1 -monitor stdio -cdrom /usr/share/virtio-win/virtio-win.iso 3.on host for ((;;)) do python serial-host-receive.py /tmp/helloworld1 done for ((;;)) do python serial-host-send.py /tmp/helloworld2 done 4.on guest Also do an endless loop for send/receive data. Actual results: Error messages pop up from monitor and guest seems stopping sometimes but it comes back after a while . Expected results: The data should be transferred fluently and there is no stop for guest. Additional info: Error message from guest. (qemu) qemu-kvm: virtio-serial-bus: Unexpected port id 2172169646 for device virtio-serial0.0 (qemu) (qemu) (qemu) (qemu) (qemu) qemu-kvm: virtio-serial-bus: Unexpected port id 2182475182 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 2182475182 for device virtio-serial0.0 (qemu) qemu-kvm: virtio-serial-bus: Unexpected port id 2182475182 for device virtio-serial0.0 main-loop: WARNING: I/O thread spun for 1000 iterations qemu-kvm: virtio-serial-bus: Unexpected port id 2407521144 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 2267396584 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 432 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 0 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 2254446600 for device virtio-serial0.0 qemu-kvm: virtio-serial-bus: Unexpected port id 2182475182 for device virtio-serial0.0
host info qemu-kvm-common-1.5.1-2.el7.x86_64 qemu-kvm-1.5.1-2.el7.x86_64 qemu-kvm-debuginfo-1.5.1-2.el7.x86_64 qemu-kvm-tools-1.5.1-2.el7.x86_64 kernel-3.10.0-0.rc6.62.el7.x86_64
Please keep transferring data for a long time,it will help to reproduce the issue.
dengmin ,Pls try to reproduce it on RHEL6 and let's see whether can move the bug to RHEL7 qemu-kvm component Mike
It looks like this is related to bug #949972 and is expected to be resolved on the next build (build-67).
dengmin ,pls try to verify it on build 67
Reproduced the bug via build virtio-win-1.6.5-5 Verified the bug on virtio-win-prewhq-0.1-67 on both rhel6 and rhel7 host. **************************************************** Build info for rhel6 kernel-2.6.32-411.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.397.el6.x86_64 spice-server-0.12.4-2.el6.x86_64 seabios-0.6.1.2-28.el6.x86_64 vgabios-0.6b-3.7.el6.noarch **************************************************** Build info for rhel7 kernel-3.10.0-10.el7.x86_64 qemu-kvm-1.5.2-4.el7.x86_64 vgabios-0.6c-9.el7.noarch seabios-1.7.2.2-2.el7.x86_64 spice-server-0.12.3-1.el7.x86_64 **************************************************** Steps to reproduce - please refer comment0 Actual results,there isn't error message Expected results,there isn't error message Base on above results,the issue has been fixed,thanks.
Move status to VERIFIED according to comment #7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1729.html