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 1430664 - Guest boot failed on q35 & ovmf with usb-bot device
Summary: Guest boot failed on q35 & ovmf with usb-bot device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: jingzhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-09 09:17 UTC by jingzhao
Modified: 2020-05-13 01:28 UTC (History)
9 users (show)

Fixed In Version: qemu-kvm-rhev-2.9.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-13 01:28:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
OVMF log (410.06 KB, text/plain)
2017-03-09 09:17 UTC, jingzhao 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1443040 0 high CLOSED seabios can't recognize usb 3.0 loader at boot menu 2021-02-22 00:41:40 UTC

Internal Links: 1443040

Description jingzhao 2017-03-09 09:17:56 UTC 
Created attachment 1261477 [details]
OVMF log

Description of problem:
Guest didn't boot up successfully with usb-bot device, ovmf display following error:
Enable Slot Successfully, The Slot ID = 0x1
    Address 1 assigned successfully
UsbIoPortReset: device is now ADDRESSED at 1
ASSERT /builddir/build/BUILD/ovmf-c325e41585e3/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c(1800): TrsRing != ((void *) 0)


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

OVMF-20170228-1.gitc325e41585e3.el7.noarch
qemu-kvm-rhev-2.8.0-5.el7.x86_64
3.10.0-594.el7.x86_64

How reproducible:
3/3

Steps to Reproduce:
1. Boot guest with qemu command line [1]


Actual results:
Guest didn't boot up, please check the detailed ovmf log through attachment

Expected results:
Guest can boot up successfully

Additional info:
a. guest can boot up with usb-bot on q35 + seabios
b. guest can boot up with usb-bot on pc
c. guest can boot up with usb-bot that without usb disk, just like command [2], but display error:qemu-kvm: usb-msd: Bad LUN 0

[1]/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 2G \
-smp 2,sockets=1,cores=2,threads=1 \
-enable-kvm \
-name rhel7.4 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0 \
-drive file=/home/test/migration/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-k en-us \
-debugcon file:/home/test/ovmf.log \
-global isa-debugcon.iobase=0x402 \
-serial unix:/tmp/console,server,nowait \
-boot menu=on \
-device nec-usb-xhci,id=xhci \
-qmp tcp::4446,server,nowait \
-spice port=5900,disable-ticketing -vga qxl \
-device ioh3420,id=root.0,slot=2 \
-drive file=/mnt/test/migration/ovmf.qcow2,if=none,id=drive0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads \
-device virtio-scsi-pci,id=scsi1,bus=root.0 \
-device scsi-hd,id=virtio-disk0,drive=drive0,bus=scsi1.0 \
-device usb-bot,id=bot,bus=xhci.0 \
-drive file=/mnt/test/migration/test.qcow2,if=none,cache=none,format=qcow2,id=drive4,werror=stop,rerror=stop,aio=threads \
-device scsi-hd,bus=bot.0,scsi-id=0,lun=1,drive=drive4,id=virtio-disk4 \

-monitor stdio \

[2]/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 2G \
-smp 2,sockets=1,cores=2,threads=1 \
-enable-kvm \
-name rhel7.4 \
-uuid 990ea161-6b67-47b2-b803-19fb01d30d12 \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0 \
-drive file=/home/test/migration/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-k en-us \
-debugcon file:/home/test/ovmf.log \
-global isa-debugcon.iobase=0x402 \
-serial unix:/tmp/console,server,nowait \
-boot menu=on \
-device nec-usb-xhci,id=xhci \
-qmp tcp::4446,server,nowait \
-spice port=5900,disable-ticketing -vga qxl \
-device ioh3420,id=root.0,slot=2 \
-drive file=/mnt/test/migration/ovmf.qcow2,if=none,id=drive0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads \
-device virtio-scsi-pci,id=scsi1,bus=root.0 \
-device scsi-hd,id=virtio-disk0,drive=drive0,bus=scsi1.0 \
-device usb-bot,id=bot,bus=xhci.0 \
-monitor stdio \

Thanks
Jing Zhao
Comment 2 Laszlo Ersek 2017-03-09 11:30:49 UTC 
(1) Can you please point me to documentation that claims we support usb-bot devices even as data disks?

What sense does it make to place a scsi-hd device on a usb-bot controller, rather than on virtio-scsi, in a data center virtualization scenario (where OVMF is to be used with RHV/OpenStack)?

(2) I have seen this error message before, and at that time, it was caused by a bug in USB emulation in QEMU. Please refer to QEMU commit aa6857891df6 ("xhci: generate a Transfer Event for each Transfer TRB with the IOC bit set", 2015-03-02).

Ultimately that patch of mine turned out to be wrong, but the original code was nonetheless incorrect, and Gerd fixed it differently:

88dbed3f5946 Revert "xhci: generate a Transfer Event for each Transfer TRB with
             the IOC bit set"
df0f1692db92 xhci: fix events for setup trb.

Adding Gerd.

(3) Is this a regression in either OVMF or qemu-kvm-rhev? Thanks.
Comment 3 Gerd Hoffmann 2017-03-09 14:57:32 UTC 
(In reply to Laszlo Ersek from comment #2)
> (1) Can you please point me to documentation that claims we support usb-bot
> devices even as data disks?

It's fundamentally the same as usb-storage, and it should work.

> What sense does it make to place a scsi-hd device on a usb-bot controller,
> rather than on virtio-scsi, in a data center virtualization scenario (where
> OVMF is to be used with RHV/OpenStack)?

Well, you surely don't want use usb as permanent storage, but it makes sense to boot install media from usb, or to attach virtio-win.iso as usb.

> (2) I have seen this error message before, and at that time, it was caused
> by a bug in USB emulation in QEMU. Please refer to QEMU commit aa6857891df6
> ("xhci: generate a Transfer Event for each Transfer TRB with the IOC bit
> set", 2015-03-02).

There have been more xhci emulation fixes recently.

So, please retest with qemu 2.9.x (once builds available) and report back please.
Comment 4 Ademar Reis 2017-04-27 12:30:22 UTC 
(In reply to Gerd Hoffmann from comment #3)
> (In reply to Laszlo Ersek from comment #2)
> > (1) Can you please point me to documentation that claims we support usb-bot
> > devices even as data disks?
> 
> It's fundamentally the same as usb-storage, and it should work.
> 
> > What sense does it make to place a scsi-hd device on a usb-bot controller,
> > rather than on virtio-scsi, in a data center virtualization scenario (where
> > OVMF is to be used with RHV/OpenStack)?
> 
> Well, you surely don't want use usb as permanent storage, but it makes sense
> to boot install media from usb, or to attach virtio-win.iso as usb.
> 
> > (2) I have seen this error message before, and at that time, it was caused
> > by a bug in USB emulation in QEMU. Please refer to QEMU commit aa6857891df6
> > ("xhci: generate a Transfer Event for each Transfer TRB with the IOC bit
> > set", 2015-03-02).
> 
> There have been more xhci emulation fixes recently.
> 
> So, please retest with qemu 2.9.x (once builds available) and report back
> please.

ping
Comment 5 jingzhao 2017-04-28 01:09:21 UTC 
Hi Ademar

 Can be reproduced on the qemu-kvm-rhev-2.9.0-1.el7.x86_64. 

Thanks
Jing
Comment 6 Gerd Hoffmann 2017-04-28 08:58:41 UTC 
> -device scsi-hd,bus=bot.0,scsi-id=0,lun=1,drive=drive4,id=virtio-disk4 \

That is not correct, lun must be 0.  Please retest.
Comment 7 jingzhao 2017-04-28 09:11:59 UTC 
Modified the test command and verified it on qemu-kvm-rhev-2.9.0-1.el7.x86_64

Changed the status to verified

Thanks
Jing
Comment 8 Laszlo Ersek 2017-04-28 10:48:43 UTC 
Thank you guys very much!
Note You need to log in before you can comment on or make changes to this bug.