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.

Bug 956598

Summary: qemu core dump when boot guest with more than 56 usb-storage using the companion controller (ich9-ehci-uhci.cfg)
Product: Red Hat Enterprise Linux 7 Reporter: Sibiao Luo <sluo>
Component: qemu-kvmAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0CC: acathrow, chayang, hhuang, juzhang, kraxel, michen, mrezanin, qzhang, rhod, shuang, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-1.5.0-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:35:02 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:
Attachments:
Description Flags
qemu-kvm command line.
none
core dump bt logs. none

Description Sibiao Luo 2013-04-25 09:45:33 UTC
Description of problem:
it can boot guest with 55 usb-storage using the companion controller (ich9-ehci-uhci.cfg) successfully, but the qemu will core dump when add more than 56 usb-storage using the companion controller. Both the Q35 and pc-i440fx-1.4 machine type can hit this issue.

Version-Release number of selected component (if applicable):
host info:
kernel-3.9.0-0.rc7.53.el7.x86_64
qemu-kvm-1.4.0-2.1.el7.x86_64
seabios-1.7.2-0.2.gita810e4e7.el7.x86_64
guest info:
kernel-3.9.0-0.rc7.53.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot guest with 56 usb-storage using the companion controller (ich9-ehci-uhci.cfg)
2.
3.
  
Actual results:
qemu core dump occur, i will attach the bt log and qemu-kvm command line script later.
# sh pc-i440fx-1.4.sh 
Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
qemu-kvm: /builddir/build/BUILD/qemu-1.4.0/savevm.c:1377: vmstate_register_with_alias_id: Assertion `!se->compat || se->instance_id == 0' failed.
pc-i440fx-1.4.sh: line 58: 24433 Aborted                 (core dumped)

Expected results:
it should not have any core dump.

Additional info:

Comment 1 Sibiao Luo 2013-04-25 09:46:38 UTC
(gdb) bt
#0  0x00007f5213058819 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f5213059f28 in __GI_abort () at abort.c:90
#2  0x00007f52130517f6 in __assert_fail_base (fmt=0x7f52131a02e8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7f5218b45350 "!se->compat || se->instance_id == 0", file=file@entry=
    0x7f5218b45250 "/builddir/build/BUILD/qemu-1.4.0/savevm.c", line=line@entry=1377, function=function@entry=
    0x7f5218b458c0 <__PRETTY_FUNCTION__.27973> "vmstate_register_with_alias_id") at assert.c:92
#3  0x00007f52130518a2 in __GI___assert_fail (assertion=assertion@entry=
    0x7f5218b45350 "!se->compat || se->instance_id == 0", file=file@entry=
    0x7f5218b45250 "/builddir/build/BUILD/qemu-1.4.0/savevm.c", line=line@entry=1377, function=function@entry=
    0x7f5218b458c0 <__PRETTY_FUNCTION__.27973> "vmstate_register_with_alias_id") at assert.c:101
#4  0x00007f5218a35a02 in vmstate_register_with_alias_id (dev=dev@entry=0x7f521e9bfed0, instance_id=<optimized out>, 
    instance_id@entry=-1, vmsd=0x7f5218e8e9c0 <vmstate_scsi_disk_state>, opaque=opaque@entry=0x7f521e9bfed0, 
    alias_id=alias_id@entry=-1, required_for_version=required_for_version@entry=0)
    at /usr/src/debug/qemu-1.4.0/savevm.c:1377
#5  0x00007f521891d327 in device_set_realized (obj=<optimized out>, value=<optimized out>, err=0x7ffff87b33c0)
    at hw/qdev.c:687
#6  0x00007f521899320e in property_set_bool (obj=0x7f521e9bfed0, v=<optimized out>, opaque=0x7f521e9c0110, 
    name=<optimized out>, errp=0x7ffff87b33c0) at qom/object.c:1222
#7  0x00007f52189958f7 in object_property_set_qobject (obj=0x7f521e9bfed0, value=<optimized out>, name=
    0x7f5218b17f80 "realized", errp=0x7ffff87b33c0) at qom/qom-qobject.c:24
#8  0x00007f5218994890 in object_property_set_bool (obj=obj@entry=0x7f521e9bfed0, value=value@entry=true, 
    name=name@entry=0x7f5218b17f80 "realized", errp=errp@entry=0x7ffff87b33c0) at qom/object.c:765
#9  0x00007f521891c38a in qdev_init (dev=dev@entry=0x7f521e9bfed0) at hw/qdev.c:161
#10 0x00007f5218923df2 in scsi_bus_legacy_add_drive (bus=bus@entry=0x7f521e9bf148, bdrv=bdrv@entry=0x7f521e6bde30, 
    unit=unit@entry=0, removable=<optimized out>, bootindex=-1) at hw/scsi-bus.c:228
#11 0x00007f521893bdd5 in usb_msd_initfn_storage (dev=0x7f521e9bda60) at hw/usb/dev-storage.c:626
#12 0x00007f5218930dfd in usb_device_init (dev=0x7f521e9bda60) at hw/usb/bus.c:97
#13 usb_qdev_init (qdev=0x7f521e9bda60) at hw/usb/bus.c:214
#14 0x00007f521891bcee in device_realize (dev=0x7f521e9bda60, err=0x7ffff87b34c0) at hw/qdev.c:175
#15 0x00007f521891d2c7 in device_set_realized (obj=0x7f521e9bda60, value=<optimized out>, err=0x7ffff87b35c0)
    at hw/qdev.c:673
#16 0x00007f521899320e in property_set_bool (obj=0x7f521e9bda60, v=<optimized out>, opaque=0x7f521e9c3990, 
    name=<optimized out>, errp=0x7ffff87b35c0) at qom/object.c:1222
#17 0x00007f52189958f7 in object_property_set_qobject (obj=0x7f521e9bda60, value=<optimized out>, name=
    0x7f5218b17f80 "realized", errp=0x7ffff87b35c0) at qom/qom-qobject.c:24
#18 0x00007f5218994890 in object_property_set_bool (obj=obj@entry=0x7f521e9bda60, value=value@entry=true, 
    name=name@entry=0x7f5218b17f80 "realized", errp=errp@entry=0x7ffff87b35c0) at qom/object.c:765
#19 0x00007f521891c38a in qdev_init (dev=dev@entry=0x7f521e9bda60) at hw/qdev.c:161
#20 0x00007f5218918245 in qdev_device_add (opts=0x7f52198ab130) at hw/qdev-monitor.c:494
#21 0x00007f52189c9159 in device_init_func (opts=<optimized out>, opaque=<optimized out>) at vl.c:2283
#22 0x00007f5218af967b in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x7f52189c9140 <device_init_func>, 
    opaque=opaque@entry=0x0, abort_on_failure=abort_on_failure@entry=1) at util/qemu-option.c:1128
#23 0x00007f52188405c3 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4214
(gdb)

Comment 2 Sibiao Luo 2013-04-25 09:49:05 UTC
Created attachment 739776 [details]
qemu-kvm command line.

Comment 3 Sibiao Luo 2013-04-25 09:49:40 UTC
Created attachment 739778 [details]
core dump bt logs.

Comment 4 Sibiao Luo 2013-04-26 02:53:32 UTC
Tried the windos2012-64 that also hit the same issue, qemu core dump when add more than 56 usb-storage using the companion controller. 
If just only use the uhci controller(do not use the companion controller) also can hit the same issue.

Comment 5 Gerd Hoffmann 2013-05-14 12:42:58 UTC
usb hubs nesting too deep.
qemu 1.5 will verify this (commit c24e4aac3bd7dd6591e26b77985e5d3915ecbe4b).

Comment 6 Gerd Hoffmann 2013-05-14 14:25:25 UTC
*** Bug 920104 has been marked as a duplicate of this bug. ***

Comment 7 Miroslav Rezanina 2013-05-23 11:55:12 UTC
Build in qemu-kvm-1.5.0-1.el7

Comment 8 Sibiao Luo 2013-07-08 08:52:42 UTC
Tried this issue on qemu-kvm-1.5.1-2.el7.x86_64 with the same steps as comment #0 that qemu did not core dump when add more than 56 usb-storage(e.g: 57) using the companion controller, it will give a prompt that usb hub chain too deep.

host info:
3.10.0-0.rc7.64.el7.x86_64
qemu-kvm-1.5.1-2.el7.x86_64
guest info:
3.10.0-0.rc7.64.el7.x86_64

Results:
QEMU 1.5.1 monitor - type 'help' for more information
(qemu) qemu-kvm: -device usb-storage,drive=usb43,id=usb43: usb hub chain too deep
qemu-kvm: -device usb-storage,drive=usb43,id=usb43: Device initialization failed.
qemu-kvm: -device usb-storage,drive=usb43,id=usb43: Failed to initialize USB device 'usb-hub'
qemu-kvm: -device usb-storage,drive=usb44,id=usb44: Error: tried to attach usb device QEMU USB MSD to a bus with no free ports
qemu-kvm: -device usb-storage,drive=usb44,id=usb44: Device initialization failed.
qemu-kvm: -device usb-storage,drive=usb44,id=usb44: Device 'usb-storage' could not be initialized
/etc/qemu-ifdown: could not launch network script

Gerd Hoffmann, could you help see it if the expected result? we can set it to verified status if this result is expected. btw, how many usb storage does qemu support without multifunction ?

Best Regards,
sluo

Comment 9 Gerd Hoffmann 2013-07-22 14:36:03 UTC
(In reply to Sibiao Luo from comment #8)
> Tried this issue on qemu-kvm-1.5.1-2.el7.x86_64 with the same steps as
> comment #0 that qemu did not core dump when add more than 56
> usb-storage(e.g: 57) using the companion controller, it will give a prompt
> that usb hub chain too deep.

> (qemu) qemu-kvm: -device usb-storage,drive=usb43,id=usb43: usb hub chain too
> deep

That is the expected response, yes.  You can see the usb device tree using 'lsusb -t' in the guest.  If you plug a bunch of usb hubs first (-device usb-hub) to avoid the deep chaining of the hubs you can connect more devices.

Theoretical limit is 255 devices per usb bus.  Testing up to 32 or 64 devices per controller should be good enough for all practical purposes though.

Comment 10 Sibiao Luo 2013-07-23 01:34:03 UTC
According to comment#8 and comment#9, set this issue to verified status, thanks for Gerd. Please correct me if any mistake.

Best Regards,
sluo

Comment 11 Suqin Huang 2013-08-02 09:31:56 UTC
(In reply to Gerd Hoffmann from comment #9)
> (In reply to Sibiao Luo from comment #8)
> > Tried this issue on qemu-kvm-1.5.1-2.el7.x86_64 with the same steps as
> > comment #0 that qemu did not core dump when add more than 56
> > usb-storage(e.g: 57) using the companion controller, it will give a prompt
> > that usb hub chain too deep.
> 
> > (qemu) qemu-kvm: -device usb-storage,drive=usb43,id=usb43: usb hub chain too
> > deep
> 
> That is the expected response, yes.  You can see the usb device tree using
> 'lsusb -t' in the guest.  If you plug a bunch of usb hubs first (-device
> usb-hub) to avoid the deep chaining of the hubs you can connect more devices.
> 
> Theoretical limit is 255 devices per usb bus.  Testing up to 32 or 64
> devices per controller should be good enough for all practical purposes
> though.

Hi Gerd,
Confused why we can attach 64 devices to one controller.
As we know 4 ports for xhci, 8 ports for hub, the max devices should be 4*8=32.

Why can we attach 64 devices?

attach hub to hub? so max : 4*8*8 = 256 ?

Thanks
Suqin

Comment 12 Gerd Hoffmann 2013-08-02 10:20:42 UTC
Yes, hubs can be chained (not unlimited, but enougth for 64 devices).  Just plug in the number of hubs you need (7 or 8 I think), the first 4 go into the root ports, the other ones into the first hub, giving you enougth ports to connect around 55 usb sticks (the 64 limit is sticks + hubs summed up)

Comment 14 Ludek Smid 2014-06-13 10:35:02 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.