Linux

xhci_hcd module turns off usb host controller on boot

Bug #1668105 reported by Richard
60
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Confirmed
High
Unassigned

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
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /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
RelatedPackageVersions:
 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.

See original description
Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Created attachment 211371
Dmesg output with broken usb

I have a Apple Inc. MacBookPro11,1 (with the most recent 'bios': BIOS MBP111.88Z.0138.B16.1509081438 09/08/2015).

At the beginning, USB worked normally. After a while (and after newer kernel versions released by debian?) things started to act strangely. For one, the bios/efi boot takes a very long time (probably due to the same reason I describe later) just to get to the bootloader/grub. Likley resetting and probing for USB ports/mass storage. When grub finally pops up, I can use the (internal USB based keyboard) normally to select a grub entry etc.

Booting the kernel then works reasonably fine, until it loads the xhci module.
It spews some messages in dmesg (taking some 15 seconds) and only then, the keyboard starts to work again.

The log is filled with messages like:
[ 7.248479] xhci_hcd 0000:00:14.0: Command completion event does not match command
[ 7.248495] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 12.256347] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 12.256363] usb 1-2: hub failed to enable device, error -62
[ 17.264166] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
(followed by USB hub/device enumeration)

I've tried several combinations and quirks, updating to the latest rc kernels since 3.16 (am on 4.5.0 right now) and it only seems to get worse.

Last year, on the 3.x series of kernels occasionally after a reboot the 'bios' would go through quickly and fine and also no problems loading the module and logging in. But now it always fails.

Additionally it (may or may not) seems to cause the internal usb card reader to not even show up almost all of the time, though under OSX it works fine. There is/was a known issue with this cardreader where it would disappear after a suspend.

Adding various seemingly related intel usb3 quirks I had no change, as I think all of them are already applied to this chipset.

I'm guessing that somehow the usb chipset has some configuration option miss-set (which persists over reboots/power down) and the driver doesn't quite understand it.

Unfortunately it seems that this chipset does not work in pure USB2.0 (ehci) mode and needs the xhci module to work at all, so even falling to USB2 is no option. Also disconnecting all USB perhipials is nearly impossible as the touchpad, bluetooth cardreader and keyboard are internally all wired to USB.

I'm attaching 3 dmesg logs with various kernels and levels of debugging information. I tried to google for errors from these logs, but to no avail.

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Created attachment 211381
lots of xhci spewing with usb debug output enabled

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Created attachment 211391
dmesg on 4.4.0-rc2 with broken usb output

Revision history for this message
In , greg (greg-linux-kernel-bugs) wrote :

On Fri, Apr 01, 2016 at 11:29:19AM +0000, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=115741
>
> Bug ID: 115741
> Summary: XHCI is slow during boot (bios/efi) and leaves many
> dmesg messages

Please send to the <email address hidden> mailing list.

Revision history for this message
In , fortizc (fortizc-linux-kernel-bugs) wrote :

Hi I have a very similar issue I use Debian with kernel 4.5 in a macbook pro 12.1
boot take a long time before show grub, but when it appear the keyboard is almost useless... you have a "windows time" where the keyboard respond this "windows" are random, they come and go, the best opportunity is press enter key before grub pops up (with this boot with default entry) this erratic behavior is present in all "special boot options" of the macbook pro (see https://support.apple.com/en-us/HT201255) the touch pad have the same problems. One of this special boot options (pressing "D") is a hardware diagnostics in this test my card reader show an error VDC001. On OSX the card reader work fine, but Debian cannot see it.

Olivier can you do a hardware test? turn on your Mac with the D key pressed.

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

I have run the diagnostic mode a few times before, but never found an issue there. I'll run it again tonight and report if there is a problem. E.g. no news means diagnostic thinks everything is okay :)

The problem still persists btw, and the linux-sub mailinglist has gotten little attention ...

http://thread.gmane.org/gmane.linux.usb.general/139697

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

I ran the diagnostic mode a few times since, and as expected, no problems whatsoever.

Because of some rework I ran from an USB driver (ubuntu 16.04) and it also had the same problems. I'm running 4.6.1 right now (from git) and still the same issue.

On the ML nothing is happening in this area ...

Revision history for this message
In , robin.marlow (robin.marlow-linux-kernel-bugs) wrote :

I have the same problems with long wait from chime to bootmanager (refind) and then long waits between keypresses. Occasionally after a reboot it works normally, but never cold. Did any of you find a solution to this?

I'm using Gentoo with kernel 4.4.1 (have tried 4.6 but was no better)

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Problem persists. Meanwhile I now also have a MacBookPro12,1 and so far I don't have the issue.

I would not be supprised (but this is a pure guess) that one commit of the kernel changed some setting in the hardware/chipset which causes this strange delay and may need to be 'fixed back'. Reason I recon this, is even an older live disk, thus with an older kernel, still shows this problem.

Or the hardware in that gen macbook is simply bad.

Revision history for this message
In , thomas.lefebvre3 (thomas.lefebvre3-linux-kernel-bugs) wrote :

I am experiencing the same exact behavior as comments 4 and 7.
It's a MacbookPro12,1 and it does this everytime on cold boot and on reboots from Mac OS X. It does not show this behavior when rebooting from Linux.
It seems that neither my SD card reader is working from Linux nor from Mac OS X anymore.
I am really willing to help finding the root cause of this. Should you need something to help troubleshoot, please let me know.
I am starting to wonder if this is a software issue or an hardware issue.

Revision history for this message
In , mael.lavault (mael.lavault-linux-kernel-bugs) wrote :

I also experience the same issue on a MacBookPro12,1 with Fedora 25 workstation (kernel 4.9.3-200).

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

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
Revision history for this message
Richard (ismail-a) wrote : Re: xhci_kcd module turns off usb host controller on boot

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
Revision history for this message
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

Revision history for this message
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.

Revision history for this message
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
Revision history for this message
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

Revision history for this message
Richard (ismail-a) wrote :

Causes:

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.

Revision history for this message
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.

Revision history for this message
Richard (ismail-a) wrote :

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

Revision history for this message
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

Revision history for this message
Richard (ismail-a) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected yakkety
description: updated
Revision history for this message
Richard (ismail-a) wrote : CRDA.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : IwConfig.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : JournalErrors.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : Lspci.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : Lsusb.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : ProcEnviron.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : ProcModules.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : PulseList.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : RfKill.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : UdevDb.txt

apport information

Revision history for this message
Richard (ismail-a) wrote : WifiSyslog.txt

apport information

Richard (ismail-a)
summary: - xhci_kcd module turns off usb host controller on boot
+ xhci_hcd module turns off usb host controller on boot
Revision history for this message
Thiago Marcos P. Santos (tmpsantos) wrote :

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:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413440

I tried the latest kernel as of today:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.11-rc2/

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).

Revision history for this message
Thiago Marcos P. Santos (tmpsantos) wrote :

This seems to be the correlated upstream kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=115741

Revision history for this message
In , auxsvr (auxsvr-linux-kernel-bugs) wrote :

Similar issue (too slow to boot, error messages with XHCI) on a Macbook pro 12,1 with openSUSE Tumbleweed (linux 4.10.1). Apple's diagnostic test indicates no hardware issue.

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

A small update, the new MacBookPro12,1 has even become worse then before. (I still have the older one, which also still has the issue).

Initially it was fine, but as time went on, it became worse and worse. Booting now takes a couple of minutes.

First the time from chime to systemd-boot takes forever. Changing the menu is almost impossible as it takes forever for the (usb) keyboard to go through the menu. It probably is constantly restarting/timing out.

Once it is passed that, it is reasonably okay.

After susppend it's pretty much the same, where it sometimes works reasonably fast, other times can take a minute for USB to start working again.

(log after a reasonable fast working USB):
[156101.125279] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[156101.333046] usb 2-3: device not accepting address 31, error -62
[156106.760787] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[156112.132656] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[156112.340618] usb 2-3: device not accepting address 32, error -62
[156112.488616] usb 1-1: new high-speed USB device number 29 using xhci_hcd
[156112.628974] usb 1-1: New USB device found, idVendor=0451, idProduct=8142
[156112.628978] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[156112.628979] usb 1-1: SerialNumber: 54012851532D
[156112.629338] hub 1-1:1.0: USB hub found
[156112.629394] hub 1-1:1.0: 4 ports detected
[156118.020473] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[156123.396195] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[156123.604194] usb 2-3: device not accepting address 33, error -62
[156123.632194] usb usb2-port3: unable to enumerate USB device
[156123.632270] xhci_hcd 0000:00:14.0: Stop endpoint command completion for disabled slot 15

I do not have OSX installed on the NVMe disk anymore, but on an external USB3 drive, using the built in bootloader (via option/alt) is as tedious as systemd-boot (or grub2).

The bootloader is still the stock one, I have the one partition, that is fat formatted, where I have systemd-boot installed on.

Booting OSX from the external drive takes quite a while to get past the first bit, but is fine after the OS loads its usb driver. I dont' do this often, but haven't noticed any slowdowns or strange USB behaviour there. I'll double check and will respond if it is slow there too.

As a consequence, the built in card-reader does not work in linux (works fine in OSX), which isn't fully surprising as it is a USB based one.

So somehow, it seems linux is breaking the XHCI controller which is persistent through power off.

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

and since i can't edit, I'm running debian's 4.9.0-1 kernel at the moment, nothing special, no special options.

Also I boot OSX occasionally to check for firmware updates etc.

Revision history for this message
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 :
https://www.google.fr/search?q=xhci+host+controller+reset+may+cause+system+to+hang

Revision history for this message
In , kernelorg (kernelorg-linux-kernel-bugs) wrote :

this xhci_hcd still bad
it keeps turning off usb and with that the console keyboard

Now after a suspend-immediate resume 4.10.0-32-generic:
xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
xhci_hcd 0000:00:14.0: HC died; cleaning up

After that only the power button works until Apple Rescue Mode, macOS, Apple Hardware Test, back to Linux

History tells us this is not going to be fixed any time soon.

Can we REMOVE the code path leading to "Assuming host is dying, halting host." Halting the host is ALWAYS a bad idea.

On most laptops halting means no network, no keyboard, no mouse.
On all desktops I have halting means no keyboard no mouse

And xhci_hcd keeps shutting devices off at random.

Revision history for this message
In , oliver (oliver-linux-kernel-bugs) wrote :

Just to confirm, I also still have issues with usb3/xhci on the macbook. Most of the time i don't notice it much. Suspend-resume fails once a week maybe due to xhci.

My logs are generally full of xhci errors and warnings. But keyboard/mouse tend to keep working generally.

The only thing that's really amazing, is if I connect an android phone and try to adb to it, the entire xhci driver crashes and never returns. Keyboard and mouse are then dead too (obviously).

Revision history for this message
Nicolas Anquetil (anquetil-nicolas) wrote :

+1
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

Revision history for this message
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).

Revision history for this message
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.

Revision history for this message
In , daniel (daniel-linux-kernel-bugs) wrote :

I also have a MacbookPro 11,1, and even with the latest firmware, the problem is still here, unfortunately.

BIOS MBP111.88Z.0145.B00.1802091341 02/09/2018

Bit by bit, I have exactly the same problem as Oliver, from comment #1.

Revision history for this message
In , steven3k+kernelorg (steven3k+kernelorg-linux-kernel-bugs) wrote :

I experiencing the same problem as comment 4,7,9, and 12.
The MacOS hardware test reports the SD card reader as not working.

I am using Debian stable with kernel 4.19.67.

I don't have Mac OS installed but booting into either the online or the offline recovery doesn't fix the problem (contrarily to some other reports I found on other forums).

I can also confirm that, somehow, using adb with an Android phone often leads to unresponsive USB, including keyboard and touchpad, as reported by comment 15.

Bug Watch Updater (bug-watch-updater)
Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , kernel (kernel-linux-kernel-bugs) wrote :

Maybe you could try some more recent kernel. I'm currently running 5.7.19 without having the timeouts.

Revision history for this message
In , tobachmann (tobachmann-linux-kernel-bugs) wrote :

Starting with kernel 5.14.14 I can't boot anymore. XHCI dies early on and won't allow me to decrypt my LUKS encrypted root partition.

Revision history for this message
In , gregkh (gregkh-linux-kernel-bugs) wrote :

On Fri, Nov 05, 2021 at 10:54:24AM +0000, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=115741
>
> --- Comment #19 from Tobias Bachmann (<email address hidden>) ---
> Starting with kernel 5.14.14 I can't boot anymore. XHCI dies early on and
> won't
> allow me to decrypt my LUKS encrypted root partition.

Different issue, should be fixed in the next 5.14.y release:
 https://<email address hidden>

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

Other bug subscribers

Remote bug watches

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