Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
(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)?
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
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.
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?
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 ***