xhci_hcd module turns off usb host controller on boot

Bug #1668105 reported by Richard on 2017-02-26
This bug affects 10 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

So we know this xhci_kcd was always shit in that it turns off the console usb keyboard for long running computers and that it on abrupt termination of Linux puts usb in a 12x slower mode. It is buggy, it was always buggy, and its getting worse.

With Linux 4.8.0-37, this crappy software decides to halt the host controller on boot, ie. turn off the console keyboard preventing any boot. I cannot think of any situation where anyone would want their host controller halted.

This is MacBook Pro 2015. So, it's already broken in UEFI-grub as it always was, ie. every key press takes 8 seconds, but you only need two, so you can boot in 16 s.

I tried to disable the xhci_kcd crap by using kernel parameter noxhci_port_switch or modprobe.blacklist=xhci_hcd neither which works.

Because it has crap in UEFI, the computer will not boot any external hard drive or usb fob. The only thing that works is Apple rescue that gets rid of the xhci garbage, and the boot os x immediately after that.

So the log output
xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
- and a bit later:
xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
xhci_hcd 0000:00:14.0: HC died; cleaning up

This clown programming of Linux has to stop. Why would anyone ever want their host controller halted?
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
 /dev/snd/controlC1: foxyboy 5662 F.... pulseaudio
 /dev/snd/controlC0: foxyboy 5662 F.... pulseaudio
CurrentDesktop: GNOME
DistroRelease: Ubuntu 16.10
HibernationDevice: RESUME=/dev/mapper/C89-SWAP
MachineType: Apple Inc. MacBookPro12,1
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-39-generic root=/dev/mapper/C89-RFS ro i915.enable_rc6=0
ProcVersionSignature: Ubuntu 4.8.0-39.42-generic 4.8.17
 linux-restricted-modules-4.8.0-39-generic N/A
 linux-backports-modules-4.8.0-39-generic N/A
 linux-firmware 1.161.1
Tags: yakkety
Uname: Linux 4.8.0-39-generic x86_64
UpgradeStatus: Upgraded to yakkety on 2016-11-16 (108 days ago)
UserGroups: adm docker libvirt libvirtd sudo
_MarkForUpload: True
dmi.bios.date: 10/26/2015
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP121.88Z.0167.B15.1510261437
dmi.board.name: Mac-E43C1C25D4880AD6
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro12,1
dmi.chassis.type: 9
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-E43C1C25D4880AD6
dmi.modalias: dmi:bvnAppleInc.:bvrMBP121.88Z.0167.B15.1510261437:bd10/26/2015:svnAppleInc.:pnMacBookPro12,1:pvr1.0:rvnAppleInc.:rnMac-E43C1C25D4880AD6:rvrMacBookPro12,1:cvnAppleInc.:ct9:cvrMac-E43C1C25D4880AD6:
dmi.product.name: MacBookPro12,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1668105

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete

No logs are available.

The preboot UEFI environment is broken and was always broken, but patient people could make the mac boot.
What is new is that during boot xhci_kcd halts all usb at early boot, so no console keyboard is available. That xhci thing was always a trouble maker of poor quality.

I am working on making macOs run in the mean-time, its way old and never updated.
It is possible that I after that can make a fresh (old-version) install of Linux to a partition I conveniently left on the ssd.

Once macOS boots nicely, If there is a way to kill off everything that smells like xhci, then the existing installation may be able to boot
- I may at some point be able to remove xhci from initramfs
If it is possible to "repair" the broken uefi provided by Linux, that would be good to

And of course Linux can't read mac encryption and mac can't read Linux encryption.

Just another Linux refusing to run on fancy hardware. This is super-mainstream 18 months old, why can't Linux run it?

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Richard (ismail-a) wrote :

I guess what's next is that break= kernel command line parameter but it's not going to be doable when each keypress is 8 s

Richard (ismail-a) wrote :

The only thing that makes Linux UEFI run usb well is a gracefully shutdown Linux installation.

Because no Linux presently can boot, that's not happening.

Because the ssd is soldered, if Linux fucks up UEFI, the computer won't boot and the data is inaccessible. I there no failsafe uefi, no keyboard, and no nada.

maybe I can gracefully shutdown a pxe booted Linux and all problems will be gone.

Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.10 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10.1

Changed in linux (Ubuntu):
importance: Undecided → High
tags: added: kernel-da-key
Richard (ismail-a) wrote :

A get-around has been found allowing the system to boot:

1. Boot the Apple computer to grub, takes about 2 minutes
2. Press a key, then edit your boot configuration to include the kernel command line parameter break, takes about 2 minutes
3. At the initramfs prompt usb works fine. Enter command reboot
4. This initiates a graceful shutdown of Linux, and the Apple computer can now be booted with usb3 operating normally

Richard (ismail-a) wrote :


Since beginning of Apple UEFI, Linux UEFI has booted with usb3 in bad mode during the UEFI boot sequence. This was the case whenever the previous shutdown was not a graceful Linux shutdown, ie. a crash, abrupt shutdown by long press on power key or a macOS session. Because the wait between a key presses and it being effective, boot is cumbersome. Additionally, in the bad mode, timers are 12x slower so every grub second is 12 s, and the UEFI boot additionally takes 1 to 2 minutes.

The bad mode entailed that mouse and keyboard only works for 2 s every 10-20 s with a type-ahead buffer of about 10 characters. The bad mode was active during the UEFI phase until the kernel loaded from the boot directory.

Linux always had usb3 problems, which can be shown by any computer with usb3 hardware, and thus the xhci_hcd kernel module, over time shutting down various usb devices or the entire usb subsystem. This is what causes the console keyboard to be dead on a computer with a month or more of up-time, forcing a power off should networked ssh become unavailable.

Before kernel 4.8, the usb3 troubles only affected Linux. macOS and the UEFI Startup Manager (option-boot) were not affected.

With kernel 4.8, the presence of a Linux installation affects the boot manager and regular macOS boot making the only boot option Apple rescue mode (option+R.) All booting not preceded by a graceful Linux shutdown is also extremely slow, about 2 minutes.
- The way to boot macOS is to boot Apple rescue mode that resets usb, then boot macOS
- The way to boot Linux is the get-around above

Additionally in 4.8, the xhci_kcd module, that is built-in and cannot be removed, decides to halt the usb host controller making password input impossible. This is what prevents booting without get-around tricks.

usb3 has been a problem in Linux since its introduction. It's time to fix that.

Richard (ismail-a) wrote :

It has also been shown in Startup Manager and bad mode, plugging in an external keyboard and waiting a minute or so enables the external keyboard functioning normally.

Richard (ismail-a) wrote :

Correction: Booting to Apple rescue mode is done by pressing command+R during boot

Richard (ismail-a) wrote :

The kernel 4.8 also prevents UEFI Startup Manager from booting external usb devices such as fobs or hard drives.

Possibly booting to Startuop Manager and then from thunderbolt or pxe still works

apport information

tags: added: apport-collected yakkety
description: updated
Richard (ismail-a) wrote : CRDA.txt

apport information

apport information

apport information

apport information

Richard (ismail-a) wrote : Lspci.txt

apport information

Richard (ismail-a) wrote : Lsusb.txt

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Richard (ismail-a) on 2017-03-04
summary: - xhci_kcd module turns off usb host controller on boot
+ xhci_hcd module turns off usb host controller on boot

Get exactly the same as described here on a Macbook Pro 12,1.

Long time for booting (mostly stuck at grub), pressing a key there takes 10s to get any visual feedback and USB sometimes doesn't work at the login screen. When it works, if I plug a phone, after a while it shuts down completely.

Logs when it works are like:

I tried the latest kernel as of today:

Mainline kernel did not work, I'm trying now to recompile the stable kernel with xhci_hcd as a module and possibly blacklist it (see if fallbacking to ehci_hcd fixes at least usage after the long boot).

This seems to be the correlated upstream kernel bug:

Mathieu M (fatal974) wrote :

I updated to kernel 4.12 and the kernel recover usb failures on boot
( the clue was that the usb live cd booted , recovering usb failures, with ubuntu 17.04 kernel 4.10 )

+ i booted on macos , and updated the system from the default macos updater : some stuff on the "bios" should have been updated and now everything is fine

I dig into the intel problems and found this , for the record :

Having the same problems here :-(

Solution in post #6 and post #28 are not working

Symptoms: Mac working with normally with ubuntu 17.04
It seems that when I plugin one usb mouse I have at home this f*up the system and I can no longer use the mouse, trackpad, keyboard :-(
System is running as I can ssh to it from another computer.
Rebooting ubuntu does not help. Actually the system cannot shutdown properly, I have to turn it off (long press on the power button)
updated to kernel image 4.12 to no avail

Problem might also be due to putting the computer to sleep (I read somewhere that it was not flawless on my mac, but I use suspend a lot)

I found different posts on the web reporting various USB problems (with camera, drive, etc)
But no solution yet

raffraffraff (raffraffraff) wrote :

I'm also using a MacBook Pro 2015, but with Ubuntu 17.10. I'm not seeing exactly the same symptoms. Specifically, I do not get 'Assuming host is dying, halting host.'

I do get these symptoms:
1. On boot, each key press takes about 8 seconds (affects Mac restore and Grub, making it almost impossible to use them). By the time the Linux kernel starts, everything speeds up, and I have no problem entering a luks passphrase.
2. Very occasionally my keyboard and mouse completely stop working and I have to reboot
3. Resuming from sleep, there is a 3-4 minutes period where USB devices won't work and I get a ton of "xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command" messages.

I've had these issues since 16.04 I think.

I'm also going to compile a kernel with xhci_hcd as a module and then blacklist (just to test).

raffraffraff (raffraffraff) wrote :

Update: I've compiled the 4.13.19 kernel without USB 3 support (in the hope that it would fall back to the USB 2 module - it doesn't - you end up with no keyboard or trackpad). If you're running a system that has a BIOS, and it allows you to turn off USB 3.0 support, that seems to be the only option. Otherwise it appears that you're stuck with intermittent USB. It sucks that MacBooks don't have ethernet... I'm using a shared wifi AP even though I have a gigabit cable on my desk :(

There's a ton of USB 3.0 kernel bug tickets on launchpad, and in most cases they end up expiring due to lack of updates. This one will likely go the same way.

If ANYONE with a MacBook has managed to get it to work without USB 3.0 in the kernel, post here or PM me.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.