Bug 1411632

Summary: [Q35] qemu core dump when disk attached to 5 layers switch with bootindex parameter
Product: Red Hat Enterprise Linux 7 Reporter: jinchen
Component: qemu-kvm-rhevAssignee: Marcel Apfelbaum <marcel>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 7.4CC: chayang, jinzhao, juzhang, knoel, marcel, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-12 11:31:35 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:

Description jinchen 2017-01-10 07:42:28 UTC
Description of problem:
[Q35] qemu core dump when disk attached to 5 layers switch with bootindex parameter

Version-Release number of selected component (if applicable):
kernel-3.10.0-537.el7.x86_64
qemu-kvm-rhev-2.6.0-29.el7.x86_64

How reproducible:
3/3

Steps to Reproduce:

1. Boot guest with cmdline 1

[1]
/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 4G \
-smp 2,sockets=2,cores=1,threads=1 \
-enable-kvm \
-name test \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-smbios type=1,manufacturer='Red Hat',product='RHEV Hypervisor',version=el6,serial=koTUXQrb,uuid=feebc8fd-f8b0-4e75-abc3-e63fcdb67170 \
-k en-us \
-serial unix:/tmp/serial0,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-chardev file,path=/home/seabios.log,id=seabios \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-vga qxl \
-spice port=5933,disable-ticketing \
-qmp tcp:0:3333,server,nowait \
-drive file=/home/qcow2+raw/qcow2/test.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads \
-device ioh3420,id=root.0,slot=0 \
-device x3130-upstream,id=upstream_1,bus=root.0 \
-device xio3130-downstream,id=downstream_1,bus=upstream_1,chassis=1 \
-device xio3130-downstream,id=downstream,bus=upstream_1,chassis=2 \
-device x3130-upstream,id=upstream_2,bus=downstream_1 \
-device xio3130-downstream,id=downstream_2,bus=upstream_2,chassis=3 \
-device x3130-upstream,id=upstream_3,bus=downstream_2 \
-device xio3130-downstream,id=downstream_3,bus=upstream_3,chassis=4 \
-device x3130-upstream,id=upstream_4,bus=downstream_3 \
-device xio3130-downstream,id=downstream_4,bus=upstream_4,chassis=5 \
-device x3130-upstream,id=upstream_5,bus=downstream_4 \
-device xio3130-downstream,id=downstream_5,bus=upstream_5,chassis=6 \
-device virtio-net-pci,netdev=dev1,mac=9a:e8:e9:ea:eb:e0,id=net1,bus=downstream \
-netdev tap,id=dev1,vhost=on  \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk \
-drive file=/home/test.qcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads \
-device virtio-blk-pci,drive=drive-virtio-disk1,id=virtio-disk1,bootindex=1,bus=downstream_5 \
-monitor stdio \

Actual results:
qemu core dump 

core dump file:

#0  0x00007fe590adc118 in ?? () from /lib64/libgcc_s.so.1
#1  0x00007fe590add019 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
#2  0x00007fe5905fb636 in backtrace () from /lib64/libc.so.6
#3  0x00007fe590564f24 in __libc_message () from /lib64/libc.so.6
#4  0x00007fe5905ff047 in __fortify_fail () from /lib64/libc.so.6
#5  0x00007fe5905ff010 in __stack_chk_fail () from /lib64/libc.so.6
#6  0x00007fe59aefac85 in qdev_get_fw_dev_path (dev=<optimized out>) at hw/core/qdev.c:874
#7  0x3040697363732f30 in ?? ()
#8  0x0000000000000000 in ?? ()


Expected results:
qemu boot successfully

Additional info:
1) qemu can boot successfully withouth bootindex parameter
2) qemu also core dump when bootindex = 0
3) qemu also core dump with qemu-kvm-rhev-2.6.0-28.el7_3.3

Comment 2 Marcel Apfelbaum 2017-01-12 11:31:35 UTC

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

Comment 3 Marcel Apfelbaum 2017-01-12 11:33:58 UTC
Looking at the call stack it is the same problem with qdev_get_fw_dev_path as in https://bugzilla.redhat.com/show_bug.cgi?id=1176553.
If you think it is a different issue, please feel free to re-open the BZ.