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 1386113 - [ppc64le]Boot RHEL6.8 guest with usb controller of "usb-ehci1", installation was hung
Summary: [ppc64le]Boot RHEL6.8 guest with usb controller of "usb-ehci1", installation ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: SLOF
Version: 7.3
Hardware: ppc64le
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Thomas Huth
QA Contact: xianwang
URL:
Whiteboard:
Depends On: 1410674 1436054
Blocks: 1401400
TreeView+ depends on / blocked
 
Reported: 2016-10-18 08:09 UTC by xianwang
Modified: 2017-07-27 02:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-16 12:29:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
installation_vnc (11.98 KB, image/png)
2016-10-18 08:09 UTC, xianwang 		no flags Details
installation_console (1.51 KB, text/plain)
2016-10-18 08:10 UTC, xianwang 		no flags Details
View All

Description xianwang 2016-10-18 08:09:24 UTC 
Created attachment 1211625 [details]
installation_vnc

Description of problem:
Boot a guest of "/released/RHEL-6/6.8" tr,using usb controler-"ich9-usb-ehci1",installation was hung,while the mouse can't kick in vnc screen 

Version-Release number of selected component (if applicable):
Host install tree: RHEL7.3-20161012.0
kernel: kernel-3.10.0-513.el7
qemu: qemu-kvm-rhev-2.6.0-27.el7
SLOF: SLOF-20160223-6.gitdbbfda4.el7

Guest: RHEL6.8 BE guest
driveformat: virtio_blk
nicmodel: spapr-vlan
mem: 8G
vcpu: 4

How reproducible:
3/3

Steps to Reproduce:
1.Boot a guest with "/released/RHEL-6/6.8" tr ;
2.the command of usb controller "-device ich9-usb-ehci1,id=usb1,bus=pci.0";

Actual results:
1.After executing the qemu command,the installation is hung
2.the mouse can't kick in the vnc screen,and the installation is hung with "boot"

Expected results:
installing can be finished and successful

Additional info:
1 the full command is :
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -nodefaults  \
    -machine pseries \
    -vga std  \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=03 \
    -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x4 \
    -chardev socket,id=devorg.qemu.guest_agent.0,path=/tmp/virtio_port-org.qemu.guest_agent.0-20160516-164929-dHQ00mMM,server,nowait \
    -device virtserialport,chardev=devorg.qemu.guest_agent.0,name=org.qemu.guest_agent.0,id=org.qemu.guest_agent.0,bus=virtio_serial_pci0.0  \
    -chardev socket,id=console0,path=/tmp/console0,server,nowait \
    -device spapr-vty,chardev=console0 \
    -device ich9-usb-ehci1,id=usb1,bus=pci.0 \
    -drive file=/root/RHEL6.8BE_1.qcow2,if=none,id=blk1,cache=writethrough \
    -device virtio-blk-pci,scsi=off,drive=blk1,id=blk-disk1,bootindex=1 \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/root/RHEL-6.8-20160414.0-Server-ppc64-dvd1.iso \
    -device scsi-cd,id=cd1,drive=drive_cd1,bootindex=2 \
    -device spapr-vlan,mac=9a:7b:7c:7d:7e:71,id=idtlLxAk,netdev=idlkwV8e \
    -netdev tap,id=idlkwV8e,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -m 8G \
    -smp 4 \
    -cpu host \
    -device usb-kbd \
    -device usb-mouse \
    -qmp tcp:0:8881,server,nowait \
    -vnc :1  \
    -msg timestamp=on \
    -rtc base=localtime,clock=vm,driftfix=slew  \
    -monitor stdio \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm

2 when exchange the "ich9-usb-ehci1" to "pci-ohci",the install can be completed and successful
Comment 1 xianwang 2016-10-18 08:10:59 UTC 
Created attachment 1211626 [details]
installation_console
Comment 3 xianwang 2016-10-18 10:33:17 UTC 
I tried to use "nec-usb-xhci" and the installation can continue,but when using "usb-ehci" controller, the result is failed as same as using "ich9-usb-ehci"
Comment 4 Laurent Vivier 2016-10-18 14:47:16 UTC 
looks like a bug in SLOF that doesn't detect the "enter" key is hit and it seems there is no timeout, so this hangs in the bootloader (yaboot) waiting user action.

I've tested a 7.3 guest and the problem is the same: you can't select the kernel to boot in the grub menu.

Thomas, do you know if EHCI should work in SLOF?
Comment 5 Thomas Huth 2016-10-18 15:01:16 UTC 
There is an EHCI driver in SLOF, but AFAIK it's in a very rough shape and likely pretty much untested. So it's very likely that there is a problem with the EHCI driver of SLOF here.
Comment 6 xianwang 2016-10-19 02:47:19 UTC 
I test this problem in X86_64 host, and this problem doesn't exist for x86_64
Comment 7 Thomas Huth 2016-10-19 13:28:37 UTC 
A shorter command line to reproduce the problem with the non-working keys:

qemu-system-ppc64 -nodefaults -vga std -device usb-ehci -device usb-kbd

You then can't input any characters at the firmware prompt - but it works if you use "pci-ohci" instead of "usb-ehci".

I've now also had a closer look at the problem, and apparently the EHCI driver in SLOF does not support "interrupt transfers" (the .poll_intr function is missing), which is required for the USB keyboard driver to work...
Comment 8 Thomas Huth 2017-01-08 08:21:49 UTC 
Note that we're currently considering to disable EHCI completely for qemu-kvm-rhev on ppc64le (see BZ 1410674) ... so if EHCI gets disabled, we likely have to close this bug as WONTFIX.
Comment 9 Thomas Huth 2017-01-16 12:29:21 UTC 
EHCI controller has been disabled for ppc64le now (see BZ 1410674), so there is no point in fixing SLOF here anymore. Please remove EHCI from the ppc64le test plans.
Note You need to log in before you can comment on or make changes to this bug.