Bug 1043368 - [virtio-win][vioser]virtioserialport can not be used sometimes with error 995
Summary: [virtio-win][vioser]virtioserialport can not be used sometimes with error 995
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: rc
: ---
Assignee: Gal Hammer
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-16 06:17 UTC by Mike Cao
Modified: 2015-11-23 03:38 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-20 15:26:22 UTC
Target Upstream Version:


Attachments (Terms of Use)
screenshot when issue occurs (93.60 KB, image/png)
2014-03-21 03:18 UTC, Mike Cao
no flags Details

Description Mike Cao 2013-12-16 06:17:07 UTC
Description of problem:
Start Guest with multiple vioserialport ,sometimes the vioserialport can not be used due to "The I/O operation has been aborted because of either a thread exit or an application request "


Version-Release number of selected component (if applicable):
3.10.0-50.el7.x86_64
package qemu-kvm is not installed
qemu-kvm-rhev-1.5.3-19.el7.x86_64
seabios-1.7.2.2-4.el7.x86_64
package sgabios is not installed
seabios-bin-1.7.2.2-4.el7.noarch

How reproducible:
25%

Steps to Reproduce:
1.Start Guest with multiple viriserialport
CLI:/usr/libexec/qemu-kvm -M pc-i440fx-rhel7.0.0 -cpu SandyBridge -enable-kvm -m 2G -smp 2,cores=2 -name bcao_win-7-32-netkvm -uuid 884e673a-1b4a-4385-a522-b3cc35ef4e18 -rtc base=localtime,clock=host,driftfix=slew -drive file=win8-64.qcow2,if=none,media=disk,serial=aaabbbccc,werror=stop,rerror=stop,cache=none,format=qcow2,id=drive-disk0 -device ide-drive,bus=ide.0,unit=1,physical_block_size=4096,logical_block_size=512,drive=drive-disk0,id=disk0 -drive file=/root/en_windows_8_enterprise_x64_dvd_917522.iso,if=none,media=cdrom,id=aa -device ide-drive,id=aa1,drive=aa,bootindex=1 -drive file=/usr/share/virtio-win/virtio-win.iso,media=cdrom,if=none,id=bb -device ide-drive,id=bb1,drive=bb -netdev tap,vhost=on,id=netdev0 -device e1000,netdev=netdev0,id=nic1,mac=1a:46:0b:ca:bc:7b -vnc :1 -vga std -monitor stdio -usb -device usb-tablet,id=tablet0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -monitor unix:/tmp/tt,server,nowait
-device virtio-serial-pci,id=virtio-serial0,max_ports=16
-chardev socket,id=channel0,path=/tmp/helloworld0,server,nowait
-device virtserialport,chardev=channel0,name=com.redhat.rhevm.vdsm0,bus=virtio-serial0.0,id=port0
-device virtio-serial-pci,id=virtio-serial1,max_ports=16
-chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait
-device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial1.0,id=port1
-chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait
-device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial1.0,id=port2
-chardev socket,id=channel3,path=/tmp/helloworld3,server,nowait
-device virtserialport,chardev=channel3,name=com.redhat.rhevm.vdsm3,bus=virtio-serial1.0,id=port3,nr=11
-device virtio-serial-pci,id=virtio-serial2,max_ports=16
-chardev socket,id=channel4,path=/tmp/helloworld4,server,nowait
-device virtserialport,chardev=channel4,name=com.redhat.rhevm.vdsm4,bus=virtio-serial2.0,id=port4,nr=10
-chardev socket,id=channel5,path=/tmp/helloworld5,server,nowait
-device virtserialport,chardev=channel5,name=com.redhat.rhevm.vdsm5,bus=virtio-serial2.0,id=port5,nr=11
-chardev socket,id=channel6,path=/tmp/helloworld6,server,nowait
-device virtserialport,chardev=channel6,name=com.redhat.rhevm.vdsm6,bus=virtio-serial2.0,id=port6

2.Transferring data from guest to host in a loop by each vioserial port
  on the hosts "for ((i=0;i<=6;i++)); do python serial-host-receive.py /tmp/helloworld$i; done"
 in the guest " for ((i=0;i<=6;i++)); do VirtIOChannel_Guest_send.py com.redhat.rhevm.vdsm$i ;sleep 3 ; echo `date` >> b.txt ;done 


Actual results:
Sometimes ,one if the virtserialport can no be used for transferring data with error 995 "The I/O operation has been aborted because of either a thread exit or an application request "


Expected results:


Additional info:
Quit the VM and restart it will fix the issue

Comment 1 Mike Cao 2013-12-16 06:22:25 UTC
virito-win version :virtio-win-1.6.7-2 el3(build 70)

Comment 3 Gal Hammer 2013-12-25 14:22:56 UTC
Do you have more information? Error 995 (ERROR_OPERATION_ABORTED) mean that a the read (or write) request was cancelled.

Is it possible that the guest is trying to change state to S3?

Comment 4 Mike Cao 2013-12-26 00:22:39 UTC
(In reply to Gal Hammer from comment #3)
> Do you have more information? Error 995 (ERROR_OPERATION_ABORTED) mean that
> a the read (or write) request was cancelled.
> 
Which kind of info can I provide?
> Is it possible that the guest is trying to change state to S3?
No,I disabled s3/s4 in cli

Comment 5 Mike Cao 2014-03-20 09:36:43 UTC
Reproduced this issue again on virtio-win-prewhql-95 ,but only one time 

Steps:
1.Start VM with 3 virtio-serial-pci ,each one was attached w/ virtserialport
CLI:/usr/libexec/qemu-kvm -name 075SRL201264VFEe-kvm -m 6G -smp 8 -uuid 8ed1f259-a833-43ff-914e-ce1b2aa3070c -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/075SRL201264VFE,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=075SRL201264VFE,if=none,id=drive-ide0-0-0,format=raw,serial=mike_cao,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive if=none,id=drive-fdc0-0-0,format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:52:6e:51:a6:1d,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus -monitor stdio -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,id=channel0,path=/tmp/helloworld,server,nowait -device virtserialport,chardev=channel0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0 -device virtio-serial-pci,id=virtio-serial1,max_ports=16 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial1.0,id=port1 -device virtio-serial-pci,id=virtio-serial2,max_ports=16 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial2.0,id=port2,nr=10
2.nc -U /tmp/helloworld on the host
3.python serial-host-receive.py com.redhat.rhevm.vdsm 
4.nc -U /tmp/helloworld1 on the host
5.python serial-host-receive.py com.redhat.rhevm.vdsm1 
6.nc -U /tmp/helloworld2 on the host
7.python serial-host-receive.py com.redhat.rhevm.vdsm2

Actual Results:
step6 does not receive any data , It prompts error 995 in the guest 

Additional info
it works fine again after I kill the VM and repeat above steps

Comment 6 Mike Cao 2014-03-21 03:18:22 UTC
Created attachment 877098 [details]
screenshot when issue occurs

Comment 11 Ronen Hod 2014-12-01 16:25:11 UTC
Deferring again.
Since virtio-serial went many bug fixes, it might be already fixed by now.

Comment 15 lijin 2015-10-19 02:54:57 UTC
change status to verified according to comment#14.

Hi Amnon,

Could you please ack the related flags in order to add it into rhel7.2 errata?


Note You need to log in before you can comment on or make changes to this bug.