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 1025660 - [virtio-win][vioser]virtserialport didnot work after continuous hotplug/unplug during virtio serial in use
Summary: [virtio-win][vioser]virtserialport didnot work after continuous hotplug/unplu...
Keywords:
Status: CLOSED DUPLICATE of bug 1027181
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virtio-win
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gal Hammer
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-01 08:32 UTC by lijin
Modified: 2015-01-14 09:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-14 09:12:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description lijin 2013-11-01 08:32:20 UTC 
Description of problem:
Start guest with 1 virtio-serial-pci and 2 virtserialport,continuous unplug/hotunplug port0 and port1,since the second loop,there is always one port(port1) in "Device and Printers". And after reboot guest,there are two ports,but both ports cannot works normally.

Version-Release number of selected component (if applicable):
kernel-2.6.32-428.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.415.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64
virtio-win-1.6.7-2.el6.noarch

How reproducible:
sometimes,about 70%

Steps to Reproduce:
1.Start guest with 1 virtio-serial-pci and 2 virtio-serial-port:
/usr/libexec/qemu-kvm -drive file=win8-64.raw,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1 -device ide-drive,id=ide0-0-1,drive=drive-ide0-0-1,bootindex=0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -spice disable-ticketing,port=5900 -vga qxl -global qxl-vga.revision=3 -usb -device usb-tablet -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:e2:71:29:46,bus=pci.0 -chardev file,path=/root/console.log,id=serial1 -monitor unix:/tmp/tt,server,nowait -device isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,+sep -M rhel6.5.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -cdrom /usr/share/virtio-win/virtio-win.iso \
-device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0,nr=1 -chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1

2.Transferring data from guest to host via port0 in a loop
eg: on the host # for ((;;)) ; do python serial-host-receive.py /tmp/tt0; done
in the guest #for ((;;)) ; do python VirtIOChannel_guest_send.py com.redhat.rhevm.vdsm;done

3.Transferring data form host to guest via port1 in a loop
eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm1; done
on the host # for ((;;)) ;do python serial-host-send.py /tmp/tt1 ; done

3.Continuous hotplug/unplug virtioserialport:
cat hotunplug.sh 
for ((I=1;I<=10;I++)) ;
do
echo device_del port0 | nc -U /tmp/tt ;
sleep 3;
echo device_del port1| nc -U /tmp/tt ;
sleep 3;
echo device_add virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0 |nc -U /tmp/tt ;
sleep 3;
echo device_add virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1 | nc -U /tmp/tt ;
sleep 3;
done

Actual results:
After the second hotplug/unplug loop,port1 keeps staying in "Devices and Printers" all the time,and port0 never show up again.
After the loop end,restart guest,two ports can be seen in "Devices and Printers",but both cannot works,no data can be transferred.

Expected results:
virtserialort can be delete/add correctly,and after loop ends,virtserialport can work well.

Additional info:
Comment 2 Mike Cao 2013-11-11 14:36:21 UTC 
https://bugzilla.redhat.com/show_bug.cgi?id=1027181 may dup of this one
Comment 3 lijin 2013-12-03 07:16:53 UTC 
win2012R2 hit the same issue with virio-win-prewhql-74

package info:
qemu-kvm-rhev-0.12.1.2-2.415.el6_5.3.x86_64
kernel-2.6.32-433.el6.x86_64
seabios-0.6.1.2-28.el6.x86_64
Comment 4 Mike Cao 2013-12-12 11:53:19 UTC 
Reproduced this issue on RHEL7 hosts with virtio-win-1.6.7-2

3.10.0-50.el7.x86_64
qemu-kvm-rhev-1.5.3-19.el7.x86_64
seabios-1.7.2.2-4.el7.x86_64

steps 
1.Start VM with virtio-serial-pci and virtserialport
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=serial0 -chardev socket,path=/tmp/socket,server,nowait,id=chardev0 -device virtserialport,id=port0,name=com.redhat.rhevm.vdsm,chardev=chardev0 
2.Transferring data from guest to host in a loop
eg:in the guest # for ((;;)) ;do python VirtIOChannel_guest_send.py com.redhat.rhevm.vdsm1; sleep 1; done
on the host # for ((;;)) ;do python serial-host-recieve.py /tmp/tt1 ; done

3.(qemu) device_del port0
(qemu) device_add virtserialport,id=port0,name=com.redhat.rhevm.vdsm,chardev=chardev0


4.try to transferring data from guest to hsot again via vioserial
on the host #nc -U /tmp/socket
in the guest use #vioserial-test.exe to write sth 

Actual Restult:
in the vioserial-test.exe terminal "Write failed but isn't deplayed 
WriteTest: WriteFile failed : Error 22"
Comment 5 Gal Hammer 2013-12-29 13:12:48 UTC 
I was still unable to reproduce either one of the two scenarios. I tried with qemu-kvm-1.5.3-30.el7 which should be identical to qemu-kvm-rhev.
Comment 6 Gal Hammer 2014-03-13 13:16:38 UTC 
Closing after failing to reproduce w/qemu-kvm-1.5.3-52.el7.x86_64 on a RHEL-7 host.
Comment 7 lijin 2014-03-19 03:20:37 UTC 
win8.1-32 guest still hit this issue on rhel7 host:
steps same as comment#0

actual result:
no warning message shown in qemu monitor during hotplug/hotunplug,but still only one port can be seen in guest;
after reboot guest,two ports can be detected and neither of them can work normally.

expected result:
after the unplug/plug loop,two ports can work correctly

package info：
kernel-3.10.0-110.el7.x86_64
qemu-kvm-rhev-1.5.3-53.el7.x86_64
seabios-1.7.2.2-12.el7.x86_64
virtio-win-prewhql-75
Comment 8 Gal Hammer 2014-03-19 06:13:52 UTC 
Does it reproduce on qemu-kvm-1.5.3-52.el7.x86_64 (non rhev version)? Thanks.
Comment 9 lijin 2014-03-20 06:20:44 UTC 
(In reply to Gal Hammer from comment #8)
> Does it reproduce on qemu-kvm-1.5.3-52.el7.x86_64 (non rhev version)? Thanks.

Yes,I can reproduce this issue with qemu-kvm-1.5.3-53.el7.x86_64
Comment 13 lijin 2014-09-01 07:53:17 UTC 
test with virtio-win-prewhql-90 and qemu-kvm-0.12.1.2-2.441.el6.bz1027181.x86_64:
steps as comment#0,virtserialort can be hot-unplug/hot-plug correctly,and after the loop ends,virtserialport can work well.

package info:
qemu-kvm-0.12.1.2-2.441.el6.bz1027181.x86_64
virtio-win-prewhql-90 
2.6.32-486.el6.x86_64
Comment 14 Gal Hammer 2014-09-16 13:14:04 UTC 
Hi Mike,

Based on comment #13, can we close this one?

Second, is this a duplicate of bug 1044341 (or vice verse)?

Thanks,

    Gal.
Comment 15 Mike Cao 2014-10-08 14:54:02 UTC 
(In reply to Gal Hammer from comment #14)
> Hi Mike,
> 
> Based on comment #13, can we close this one?

We can not close it as fixed we are using stratch build on #13.
As Amit claims 1043403 originally is a RHEL7 bug.  The fix in bug 1027181 is targeted for RHEL6.  RHEL7 already has the fix mentioned there.

I think both of the 2 bugs may close as  dup of 1043403 after it fixed.
What's your idea ?

Thanks,
Mike
Comment 16 Gal Hammer 2014-10-12 13:29:46 UTC 
(In reply to Mike Cao from comment #15)
> (In reply to Gal Hammer from comment #14)
> > Hi Mike,
> > 
> > Based on comment #13, can we close this one?
> 
> We can not close it as fixed we are using stratch build on #13.
> As Amit claims 1043403 originally is a RHEL7 bug.  The fix in bug 1027181 is
> targeted for RHEL6.  RHEL7 already has the fix mentioned there.
> 
> I think both of the 2 bugs may close as  dup of 1043403 after it fixed.
> What's your idea ?

Keep just one open for tracking and close the rest as dups. No need to wait for a fix.

> Thanks,
> Mike
Comment 18 Gal Hammer 2015-01-14 09:12:56 UTC 
Closing as DUPLICATED based on comment #13.

*** This bug has been marked as a duplicate of bug 1027181 ***
Note You need to log in before you can comment on or make changes to this bug.