1044341 – [virtio-win][vioser]Transfer data failed in win8-32 guest after re-hotplug virtio-serial and serial port.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1044341 - [virtio-win][vioser]Transfer data failed in win8-32 guest after re-hotplug virtio-serial and serial port.

Summary: [virtio-win][vioser]Transfer data failed in win8-32 guest after re-hotplug vi...

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	virtio-win
Sub Component:
Version:	7.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Gal Hammer
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	1288337
TreeView+	depends on / blocked

Reported:	2013-12-18 06:52 UTC by Min Deng
Modified:	2017-01-06 06:55 UTC (History)
CC List:	14 users (show)
Fixed In Version:	virtio-win-prewhql-0.1-122
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-01-06 06:55:41 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Bugzilla	1043403	0	medium	CLOSED	can not connect to the virtio serial port on host side	2021-02-22 00:41:40 UTC

Internal Links: 1043403

Description Min Deng 2013-12-18 06:52:27 UTC

Description of problem:
Firstly,hot-unplug virtio serial pci from guest and then hot-plug virtio-serial-pci and ports again.All operation are permitted at least there wasn't any alert message.

Version-Release number of selected component (if applicable):
kernel-3.10.0-53.el7.x86_64
qemu-kvm-rhev-1.5.3-19.el7.x86_64
virtio-win 1.6.7-2 
How reproducible:
4 times

Steps to Reproduce:
1.boot up guest 
  /usr/libexec/qemu-kvm -M pc -cpu host -enable-kvm -m 4G -smp 2 -name win2k8-64-nerkvm -rtc base=localtime,clock=host,driftfix=slew -uuid 816c2e3d-e84f-4de9-b919-7d1cfd226b6d -monitor stdio -drive file=win8-32.qcow3,if=none,id=drive-data-disk2,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-data-disk2,id=systemos -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet0,mac=00:32:52:41:31:31,id=net1 -cdrom /usr/share/virtio-win/virtio-win-1.6.7.iso -vga cirrus -chardev socket,id=abc,path=/tmp/monitor-win8-64-scsi-73,server,nowait -mon chardev=abc,mode=readline -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port2 -device virtio-balloon-pci,id=balloon0 -vnc :1 
2.execute transfer scripts 
  1st :data was from host to guest
  2nd :data was from guest to host
3.device_del virtio-serial0
4.check info qtree,it removed successfully.
5.
device_add virtio-serial-pci,id=virtio-serial0,max_ports=31
device_add virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1
device_add virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port2

Actual results:The ports didn't work any more even if rebooting guest


Expected results:The ports still work or don't allow such operation.


Additional info:

Comment 1 Gal Hammer 2013-12-18 16:19:55 UTC

Please explain what does it mean when you write "ports didn't work"?

1. Is it exist in the qtree?
2. Is the port exists inside the Window guest?
3. Data it not received from the host? (bz#1027181)?

Comment 2 Min Deng 2013-12-25 10:07:30 UTC

(In reply to Gal Hammer from comment #1)
> Please explain what does it mean when you write "ports didn't work"?
> 
> 1. Is it exist in the qtree?
> 2. Is the port exists inside the Window guest?
> 3. Data it not received from the host? (bz#1027181)?
  For 3,the data could not transfer any longer via those ports.

Comment 3 Gal Hammer 2013-12-25 13:51:19 UTC

(In reply to dengmin from comment #2)
> (In reply to Gal Hammer from comment #1)
> > Please explain what does it mean when you write "ports didn't work"?
> > 
> > 1. Is it exist in the qtree?
> > 2. Is the port exists inside the Window guest?
> > 3. Data it not received from the host? (bz#1027181)?
>   For 3,the data could not transfer any longer via those ports.

Both guest-to-host and host-to-guest?

Comment 4 Min Deng 2013-12-26 05:08:27 UTC

(In reply to Gal Hammer from comment #3)
> (In reply to dengmin from comment #2)
> > (In reply to Gal Hammer from comment #1)
> > > Please explain what does it mean when you write "ports didn't work"?
> > > 
> > > 1. Is it exist in the qtree?
> > > 2. Is the port exists inside the Window guest?
> > > 3. Data it not received from the host? (bz#1027181)?
> >   For 3,the data could not transfer any longer via those ports.
> 
> Both guest-to-host and host-to-guest?

For 1,it existed in qtree after re-hotplug.
For 2,yes,the ports were found inside guest.

Both guest-to-host and host-to-guest cannot work.it still didn't work even if rebooting guest.

Comment 7 Gal Hammer 2014-03-16 13:44:45 UTC

Moved to RHEL-7 based on versions given in comment #0.

Comment 13 lijin 2014-07-22 06:39:54 UTC

win2k8r2 hit the same issue when run transfer scripts as following,ports don't work after re-hotplug:
for ((i=1;i<=1000;i++));
do
python serial-host-receive.py /tmp/helloworld1;
done

But both ports work well if I add "sleep 1" in the transfer scripts as:
for ((i=1;i<=1000;i++));
do
python serial-host-receive.py /tmp/helloworld2;
sleep 1;  
done

Comment 21 Gal Hammer 2016-07-24 09:08:13 UTC

I'm unable to reproduce with build 122, windows 8.1 and qemu 2.6.

Can you please re-test it and see if you can reproduce it with current/updated components versions? Thanks.

Comment 22 lijin 2016-07-25 01:15:21 UTC

Hi damchen,

Could you please help to handle comment#21?

Comment 23 damchen 2016-07-27 07:51:10 UTC


(In reply to lijin from comment #22)
> Hi damchen,
> 
> Could you please help to handle comment#21?

I have re-test it. The problem is  not to reproduce with build 122, windows 8.1 and qemu 2.6.

Comment 24 Gal Hammer 2016-07-27 08:04:58 UTC

(In reply to damchen from comment #23)
> 
> (In reply to lijin from comment #22)
> > Hi damchen,
> > 
> > Could you please help to handle comment#21?
> 
> I have re-test it. The problem is  not to reproduce with build 122, windows
> 8.1 and qemu 2.6.

Thanks for the confirmation.

Comment 25 Yu Wang 2016-09-19 06:25:45 UTC

Re-test with build 126 on win8-32, steps as comment#0, cannot reproduce it. So this bug has been fixed. 

Change status to verfied

Thanks
Yu Wang

Comment 26 lijin 2017-01-06 06:55:41 UTC

close as this issue has already been fixed in rhel7.3 virtio-win package

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