Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1058597

Summary: [PCIe] qemu-kvm will core dump when boot with >=24 i82801b11-bridge behind i82801b11-bridge
Product: Red Hat Enterprise Linux 7 Reporter: Jun Li <juli>
Component: qemu-kvm-rhevAssignee: Marcel Apfelbaum <marcel>
Status: CLOSED DUPLICATE QA Contact: jingzhao <jinzhao>
Severity: low Docs Contact:
Priority: low    
Version: 7.0CC: ailan, dgilbert, hhuang, jinchen, jinzhao, juzhang, knoel, michen, mst, rbalakri, virt-bugs, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-14 10:21:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1311684    

Description Jun Li 2014-01-28 06:17:02 UTC
Description of problem:
qemu-kvm will core dump when boot with >=24 i82801b11-bridge behind i82801b11-bridge.

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


How reproducible:
100%

Steps to Reproduce:
1.boot guest with the following script.
# sh 4230855-pci-bridge-behind-i82801b11-bridge-max-i82801b11-bridge.sh 24
# cat 4230855-pci-bridge-behind-i82801b11-bridge-max-i82801b11-bridge.sh 
#! /bin/sh
MACHINE=q35
SMP=2,cores=2,threads=1,sockets=1
MEM=2G
GUEST_IMG=/home/juli/rhel7.0.qcow2
IMG_FORMAT=qcow2

CLI="gdb --args /usr/libexec/qemu-kvm -enable-kvm -M $MACHINE -smp $SMP -m $MEM -name vm1 -drive file=$GUEST_IMG,if=none,id=guest-img,format=$IMG_FORMAT,werror=stop,rerror=stop -device virtio-blk-pci,drive=guest-img,id=os-disk,bootindex=1 -vnc :6 -monitor stdio -boot menu=on" 
echo "booting ..."

max_num=${1:-0}
CLI="$CLI -device ioh3420,bus=pcie.0,id=root.0,addr=0x4"
CLI="$CLI  -device i82801b11-bridge,bus=root.0,id=bridge_before.0"
for ((i=0;i<$max_num;i++)); do
    CLI="$CLI  -device i82801b11-bridge,bus=bridge_before.$((i)),id=bridge_before.$((i+1))"
done
BRIDGE_ID="bridge_before.$i"
echo "$BRIDGE_ID"
if (($max_num>=1)); then
    for ((i=1;i<=$max_num;i++)); do
        CLI="$CLI -device pci-bridge,bus=$BRIDGE_ID,id=bridge_li$i,chassis_nr=1,addr=0x1"
        BRIDGE_ID="bridge_li$i"
    done
fi
CLI="$CLI -device virtio-scsi-pci,bus=$BRIDGE_ID,id=scsi0,addr=0x1 -drive file=/home/juli/data.qcow2,if=none,id=drive-data,format=qcow2 -device scsi-hd,bus=scsi0.0,id=data-disk,drive=drive-data"
$CLI

2.
3.

Actual results:
*** qemu-kvm core dump.
qemu-kvm: /builddir/build/BUILD/qemu-1.5.3/savevm.c:1555: register_savevm_live: Assertion `!se->compat || se->instance_id == 0' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff2c9c979 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff2c9c979 in raise () from /lib64/libc.so.6
#1  0x00007ffff2c9e088 in abort () from /lib64/libc.so.6
#2  0x00007ffff2c958e6 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff2c95992 in __assert_fail () from /lib64/libc.so.6
#4  0x00005555557e5664 in register_savevm_live ()
#5  0x00005555557c6e02 in virtio_scsi_device_init ()
#6  0x00005555557ccab6 in virtio_device_init ()
#7  0x000055555567f184 in device_realize ()
#8  0x00005555556806ab in device_set_realized ()
#9  0x000055555574123e in property_set_bool ()
#10 0x0000555555743df7 in object_property_set_qobject ()
#11 0x0000555555742c00 in object_property_set_bool ()
#12 0x000055555567f69a in qdev_init ()
#13 0x00005555556f6a82 in virtio_scsi_pci_init_pci ()
#14 0x00005555556f6f92 in virtio_pci_init ()
#15 0x00005555556c3362 in pci_qdev_init ()
#16 0x000055555567f184 in device_realize ()
#17 0x00005555556806ab in device_set_realized ()
#18 0x000055555574123e in property_set_bool ()
#19 0x0000555555743df7 in object_property_set_qobject ()
#20 0x0000555555742c00 in object_property_set_bool ()
#21 0x000055555572f14e in qdev_device_add ()
#22 0x0000555555773649 in device_init_func ()
---Type <return> to continue, or q <return> to quit---
#23 0x00005555558a61bb in qemu_opts_foreach ()
#24 0x0000555555601be1 in main ()


Expected results:
No core dump. Or qemu-kvm will give some warning or error message to forbid booting.

Additional info:
the core dump info is the similar with Bug 1058200. But file this bug to record this scenarios(about the max num of i82801b11-bridge). If it is the same issue to bug 1058200, please close it. Thx.

Comment 1 Jun Li 2014-01-28 06:19:46 UTC
Add the qemu-kvm versio:
Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-41.el7.x86_64
3.10.0-79.el7.x86_64

Comment 11 Marcel Apfelbaum 2017-02-14 10:01:19 UTC
*** Bug 1421620 has been marked as a duplicate of this bug. ***

Comment 12 Marcel Apfelbaum 2017-02-14 10:03:18 UTC
Hi David,

I think I already 'passed' you a BZ with the same issue. Can you please confirm is the same issue as before so we can close one of them?

Thanks,
Marcel

Comment 13 Dr. David Alan Gilbert 2017-02-14 10:12:19 UTC
(In reply to Marcel Apfelbaum from comment #12)
> Hi David,
> 
> I think I already 'passed' you a BZ with the same issue. Can you please
> confirm is the same issue as before so we can close one of them?
> 
> Thanks,
> Marcel

Yes, I think that's the same as bz 1342434 which I just fixed upstream, so it's a fixed-in-2.9  where it gives a prettier failure.
There doesn't seem any point in backporting the fix to the qemu-kvm world since it's an unreal use case anyway.

Comment 14 Marcel Apfelbaum 2017-02-14 10:21:49 UTC
(In reply to Dr. David Alan Gilbert from comment #13)
> (In reply to Marcel Apfelbaum from comment #12)
> > Hi David,
> > 
> > I think I already 'passed' you a BZ with the same issue. Can you please
> > confirm is the same issue as before so we can close one of them?
> > 
> > Thanks,
> > Marcel
> 
> Yes, I think that's the same as bz 1342434 which I just fixed upstream, so
> it's a fixed-in-2.9  where it gives a prettier failure.
> There doesn't seem any point in backporting the fix to the qemu-kvm world
> since it's an unreal use case anyway.

Agreed,
Since is the same issue as bz 1342434 I'll close it as duplicate.

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