probe with driver ehci-pci failed with error -110

mendaxca · 2026-07-23 12:17:11

Starting from kernel 6.16, all rear USB ports do not work.
The kernels I have tested include 6.12.62, 6.15.9, 6.16, 6.16.10, 6.17.9, and 7.1.4. Version 6.15.9 is the last known good one.
I have searched the web. They suggest changing "Legacy USB Support" or "EHCI Handoff" in the BIOS. Enabling or disabling "Legacy USB Support" does not help, and there is no "EHCI Handoff" option in the BIOS settings.
The system is an Intel S1200BTL mainboard (C204 chipset) with an E3-1265L V2.

full dmesg: https://paste.c-net.org/EightSmalls
reference
https://bugs.launchpad.net/ubuntu/+sour … ug/2160707
https://darkranger.no-ip.org/content/rh … F%E9%A1%8C
https://discussion.fedoraproject.org/t/ … sma/188113

seth · 2026-07-23 16:45:41

[    0.392152] ehci-pci 0000:00:1d.0: EHCI Host Controller
[    0.392161] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 1
[    0.392179] ehci-pci 0000:00:1d.0: debug port 2
[    0.397299] ehci-pci 0000:00:1d.0: can't setup: -110
[    0.397303] ehci-pci 0000:00:1d.0: USB bus 1 deregistered
[    0.397317] ehci-pci 0000:00:1a.0: EHCI Host Controller
[    0.397326] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
[    0.397338] ehci-pci 0000:00:1a.0: debug port 2
[    0.397428] ehci-pci 0000:00:1d.0: init 0000:00:1d.0 fail, -110
[    0.397431] ehci-pci 0000:00:1d.0: probe with driver ehci-pci failed with error -110
[    0.401266] ehci-pci 0000:00:1a.0: irq 22, io mem 0xc2440000
[    0.407263] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    0.407350] usb usb1: Product: EHCI Host Controller
[    0.407352] usb usb1: Manufacturer: Linux 7.1.4-arch1-1 ehci_hcd
[    0.669249] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    1.077229] usb 1-1.1: new full-speed USB device number 3 using ehci-pci
[    1.355017] usb 1-1.6: new high-speed USB device number 4 using ehci-pci

Interestingly the second one works

8086:1c26 # bad
Intel Corporation 5 Series/C200 Series Chipset Family USB Enhanced Host Controller #1
8086:1c2d # good
Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2

Does re-scanning the bus revive the device?
https://stackoverflow.com/questions/323 … f-pcie-bus

mmy8x · 2026-07-23 21:32:57

110 is ETIMEDOUT and it appears to come from the ehci_pci_setup/ehci_setup/ehci_halt/ehci_handshake call chain. If this times out it means the chip is somewhat not responsive, though also not completely powered down or removed since that would more likely be ENODEV.

There were no relevant changes to ehci-hcd in 6.16, so it looks like a bug elsewhere - PCI, ACPI, hell knows what. It would really help if you could bisect this and find the offending commit, then we could report this upstream and hopefully get it fixed.

Is 6.12.62 good? This kernel is actually newer than 6.16 (December vs July 2025), but from the older 6.12 branch. So if it works, it tells us that the problematic change is one of those that haven't been backported to stable releases. Unfortunately, most of changes are like that, so it doesn't really tell us very much. Bisect would help.

mendaxca · 2026-07-24 04:34:06

seth wrote:

Does re-scanning the bus revive the device?

The USB ports still not work after executing 'echo 1 > /sys/bus/pci/rescan' on kernel 7.1.4. Executing or not executing 'echo 1 > /sys/devices/pci0000\:00/0000\:00\:1d.0/remove' before rescan has no effect on result.

mmy8x wrote:

Is 6.12.62 good?

Kernel 6.12.62 is good.

Thanks for your help. I will try to bisect to find out the problematic commit. It will cost some time and I will post results here.

mendaxca · 2026-07-29 16:15:34

git bisect log

git bisect start
# status: waiting for both 'good' and 'bad' commits
# bad: [038d61fd642278bab63ee8ef722c50d10ab01e8f] Linux 6.16
git bisect bad 038d61fd642278bab63ee8ef722c50d10ab01e8f
# status: waiting for 'good' commit(s), 'bad' commit known
# good: [0ff41df1cb268fc69e703a08a57ee14ae967d0ca] Linux 6.15
git bisect good 0ff41df1cb268fc69e703a08a57ee14ae967d0ca
# good: [43db1111073049220381944af4a3b8a5400eda71] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 43db1111073049220381944af4a3b8a5400eda71
# good: [11fcf368506d347088e613edf6cd2604d70c454f] uapi: bitops: use UAPI-safe variant of BITS_PER_LONG again
git bisect good 11fcf368506d347088e613edf6cd2604d70c454f
# good: [601dddb6c5d6bf63c63b2efba98231db5f861696] Merge tag 'regulator-fix-v6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good 601dddb6c5d6bf63c63b2efba98231db5f861696
# bad: [923d401238c590f39833a2015f6f9493f146d98f] Merge tag 'iommu-fixes-v6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux
git bisect bad 923d401238c590f39833a2015f6f9493f146d98f
# bad: [6daaa479ac557bc426a7fd2e913b618523fe41fd] Merge tag 'drm-xe-fixes-2025-06-26' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
git bisect bad 6daaa479ac557bc426a7fd2e913b618523fe41fd
# bad: [5c8013ae2e86ec36b07500ba4cacb14ab4d6f728] Merge tag 'net-6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect bad 5c8013ae2e86ec36b07500ba4cacb14ab4d6f728
# bad: [9afe652958c3ee88f24df1e4a97f298afce89407] Merge tag 'x86_urgent_for_6.16-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 9afe652958c3ee88f24df1e4a97f298afce89407
# bad: [4774cfe3543abb8ee98089f535e28ebfd45b975a] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect bad 4774cfe3543abb8ee98089f535e28ebfd45b975a
# bad: [f688b599d711d169b22e99f2d055847d66c4e0d3] Merge tag 'pm-6.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad f688b599d711d169b22e99f2d055847d66c4e0d3
# bad: [dd3581853c5f190c3a7bd1de78f5ecb2905a77a7] Merge branch 'pm-cpuidle'
git bisect bad dd3581853c5f190c3a7bd1de78f5ecb2905a77a7
# good: [ea2867608b311a4bcf4f231cd065825b5d8dc4f9] Merge branch 'pm-tools'
git bisect good ea2867608b311a4bcf4f231cd065825b5d8dc4f9
# bad: [a430c11f401589a0f4f57fd398271a5d85142c7a] intel_idle: Rescan "dead" SMT siblings during initialization
git bisect bad a430c11f401589a0f4f57fd398271a5d85142c7a
# bad: [4c529a4a7260776bb4abe264498857b4537aa70d] x86/smp: PM/hibernate: Split arch_resume_nosmt()
git bisect bad 4c529a4a7260776bb4abe264498857b4537aa70d
# bad: [c0f691388992c708436ab5f6e810865be6ddf5c6] intel_idle: Use subsys_initcall_sync() for initialization
git bisect bad c0f691388992c708436ab5f6e810865be6ddf5c6
# first bad commit: [c0f691388992c708436ab5f6e810865be6ddf5c6] intel_idle: Use subsys_initcall_sync() for initialization

Do you have any idea on the problem?

seth · 2026-07-29 19:55:22

https://github.com/torvalds/linux/commi … 5be6ddf5c6

It is not necessary to wait until the device_initcall() stage with intel_idle initialization

Apparently it is.
https://lore.kernel.org/all/2994397.e9J … socki.net/

Does "intel_idle.max_cstate=0" work w/ newer kernels (for posterity: that is NOT a sane solution at all! It will just disable intel_idle)

mmy8x · 2026-07-29 20:57:15

mendaxca wrote:

# first bad commit: [c0f691388992c708436ab5f6e810865be6ddf5c6] intel_idle: Use subsys_initcall_sync() for initialization

Do you have any idea on the problem?

No idea what's going on here, but this commit changes the order of some initialization which may have unintended side effects. Maybe a bad interaction with ACPI? I don't know.

The thing to do at this point is to follow instructions in Documentation/admin-guide/reporting-regressions.rst and email the author of the offending commit plus relevant mailing lists (I would try linux-acpi@vger.kernel.org, linux-usb@vger.kernel.org, regressions@lists.linux.dev) with a brief description of the problem, including the bisected commit ID and logs from the broken kernel.

I could report this myself, but it's a weird bug so I suspect people will have questions, requests to try patches, etc., and it would be better if they could reach you directly.

mendaxca · 2026-07-30 14:07:15

Specifying "intel_idle.max_cstate=0" can work around this bug.

Thanks for your help again! I have reported this regression.

Arch Linux

#1 2026-07-23 12:17:11

probe with driver ehci-pci failed with error -110

#2 2026-07-23 16:45:41

Re: probe with driver ehci-pci failed with error -110

#3 2026-07-23 21:32:57

Re: probe with driver ehci-pci failed with error -110

#4 2026-07-24 04:34:06

Re: probe with driver ehci-pci failed with error -110

#5 2026-07-29 16:15:34

Re: probe with driver ehci-pci failed with error -110

#6 2026-07-29 19:55:22

Re: probe with driver ehci-pci failed with error -110

#7 2026-07-29 20:57:15

Re: probe with driver ehci-pci failed with error -110

#8 2026-07-30 14:07:15

Re: probe with driver ehci-pci failed with error -110

Board footer