Bug 1227833

Summary: qemu-kvm sometimes dies with 1 when plug/unplugging virtserialports
Product: Red Hat Enterprise Linux 7 Reporter: Lukáš Doktor <ldoktor>
Component: qemu-kvm-rhevAssignee: David Gibson <dgibson>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: amit.shah, gklein, hannsj_uhl, huding, jsuchane, juzhang, knoel, ldoktor, michen, qzhang, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-21 04:21:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1308609, 1359843    
Attachments:
Description Flags
virt-test log of the mentioned test none

Description Lukáš Doktor 2015-06-03 15:17:52 UTC 
Description of problem:
I'm running the `virtio_console.spread_linear.specifiable.virtserialport.with_vm.interrupted_transfer.replug_recv.micro` test and sometimes qemu process dies with 1

Version-Release number of selected component (if applicable):


How reproducible:
qemu-kvm-rhev-2.3.0-1.el7

Steps to Reproduce:
1. Run qemu-kvm quest with multiple virtserialports attached
2. Execute loopback from 1st port to 2-4th ports.
3. Start sending data to 1st port and read them out from the 2-4 ports
4. hotplug and unplug the ports 2-4

Actual results:
Usually it survives couple of hotplug/unplug iterations, but after a while qemu dies returning 1

Expected results:
It should survive and the loopback should be able to resume and resend the data when the port is hotplugged back.

Additional info:
The mentioned virttest test executes 60 iterations of the hotplug unplug. In each iteration it randomly chose some of the 2-4 ports. See the log for details.
Comment 1 Lukáš Doktor 2015-06-03 15:18:20 UTC 
Created attachment 1034398 [details]
virt-test log of the mentioned test
Comment 3 Amit Shah 2015-06-11 12:06:33 UTC 
Is this ppc-specific?  Does this not trigger on x86?
Comment 4 Karen Noel 2015-06-12 10:54:35 UTC 
(In reply to Amit Shah from comment #3)
> Is this ppc-specific?  Does this not trigger on x86?

Also, was this ppc64le or ppc64? Which endian was the guest (in case it matters)?
Comment 6 Qunfang Zhang 2015-07-01 14:18:43 UTC 
Hi, Amit

According to the log attached in this BZ (10:37:51 INFO | [qemu output] qemu-kvm: Guest moved used index from 34321 to 34319), maybe this is a duplicate bug with the following ones which happen on x86 as well? 

Bug 1170391 - qemu core dump when repeadly hotplug/hotunplug serial port that transftering data
Bug 1170042 - "Guest moved used index from 337 to 336" repeatedly hotplug/hotunplug serial port that transferring data 

Thanks,
Qunfang
Comment 7 Lukáš Doktor 2015-07-28 15:20:47 UTC 
Dear Karen, the results are from BE guest running on LE host.

On 5th trial I succeeded in reproducing it with LE guest, previous runs failed with too many dropped characters (it might be a matter of setting, some chars are usually dropped when unplugging the port, the limit is probably too low).

As for x86 I tried that on F20 with F20 guest and it worked well (multiple executions). But I can't tell whether it "works" on RHEL too.
Comment 9 David Gibson 2015-08-11 07:22:57 UTC 
Hotplug while actively writing seems sufficiently edge case to me to defer to 7.3.
Comment 11 David Gibson 2016-04-11 05:14:26 UTC 
I think we want to determine if this happens with upstream qemu, or just downstream.
Comment 12 David Gibson 2016-04-21 04:18:29 UTC 
Lukas,  how exactly do I set up the loopback described in the reproduce steps?

Alternatively is there an automated test which will trigger this?  If so how would I execute it?
Comment 13 David Gibson 2016-04-21 04:21:00 UTC 
Actually... I spotted this in the virt log

10:37:51 INFO | [qemu output] qemu-kvm: Guest moved used index from 34321 to 34319

Which very strongly suggests it is the same as bug 1170391.

Closing as dupe.

*** This bug has been marked as a duplicate of bug 1170391 ***