[SOLVED] keyboard/mouse at dock not working anymore after update

2.0.33 · 2025-09-16 19:39:25

TL;DR
The dock received a firmware update at some point that broke the functionality for Linux. An update to the latest version (1.0.25 at the time of writing) brought it back into the game.
!Beware! - I initially used the HP Firmware updater on Win11 with another laptop to check for a new firmware, but it said the then installed 1.0.23 was the latest. So don't rely on the Windows tool, use fwupd under Arch to update.

======= original post ======

Hi gents,
first post, so I hope I don't act like a full noob among you pros. My peak linux years were decades ago and everything developed a lot.

I have a Thinkpad T470s and a HP USB-C G5 dock, with keyboard and mouse attached to the dock. I was able to use it no problem, but after a recent update no more joy on the mouse/keyboard. However my screens connected to the dock still work, so is my ethernet connection. Mouse/keyboard work in general, I tested the whole setup with another laptop with an old-ish Pop_OS (kernel 6.12.something) and everything is A+. I also have not changed by BIOS settings (I still call it BIOS, I am that old). So I am facing an Arch issue.

I followed https://bbs.archlinux.org/viewtopic.php?id=291931 for some inspiration and tried the following:

disable usb autosupend: no improvement
blacklist btusb module: no improvement
downgrade my kernel to the version when it was till working (6.14.9) and the one working on my other laptop (6.12.5): no improvement

lsusb shows the dock but not my HID devices
lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
Bus 001 Device 003: ID 1199:9079 Sierra Wireless, Inc. EM7455
Bus 001 Device 004: ID 8087:0a2b Intel Corp. Bluetooth wireless interface
Bus 001 Device 005: ID 04ca:7066 Lite-On Technology Corp. Integrated Camera
Bus 001 Device 006: ID 138a:0097 Validity Sensors, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 0bda:0316 Realtek Semiconductor Corp. Card Reader
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 03f0:066b HP, Inc HP USB-C Dock G5
Bus 004 Device 003: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

I have a dmesg -W while plugging in the dock here: http://0x0.st/Kcx4.txt
Also a journalctl -b: http://0x0.st/Kcw6.txt
And a lsmod: http://0x0.st/KcxW.txt

Only thing suspicious to my untrained eyes is that in the dmesg the dock is first declared unresponsive, but then registered a second time with no issue.

Any hints or pointers to what is causing this?
You help is appreciated! Thank you!

Last edited by 2.0.33 (2025-10-21 18:50:18)

seth · 2025-09-16 20:10:14

Does http://0x0.st/Kcw6.txt even have the dock attached? There's no trace of

[  269.826443] usb 4-1: New USB device found, idVendor=03f0, idProduct=066b, bcdDevice= 6.11
[  269.826470] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  269.826483] usb 4-1: Product: HP USB-C Dock G5

in that (and I mean 03f0:066b or "dock" at large)

Only thing suspicious to my untrained eyes is that in the dmesg the dock is first declared unresponsive

No concerns about

[  274.586115] pci_bus 0000:02: Allocating resources
[  274.586142] pcieport 0000:02:01.0: bridge window [io  0x1000-0x0fff] to [bus 04-38] add_size 1000
[  274.586151] pcieport 0000:02:02.0: bridge window [io  0x1000-0x0fff] to [bus 39] add_size 1000
[  274.586158] pcieport 0000:01:00.0: Assigned bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] to [bus 02-39] cannot fit 0x200000 required for 0000:02:02.0 bridging to [bus 39]
[  274.586165] pcieport 0000:02:02.0: bridge window [mem 0x00000000 64bit pref] to [bus 39] requires relaxed alignment rules
[  274.586170] pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
[  274.586177] pcieport 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-39] add_size 2000
[  274.586184] pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space
[  274.586189] pcieport 0000:01:00.0: bridge window [io  size 0x2000]: failed to assign
[  274.586193] pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space
[  274.586197] pcieport 0000:01:00.0: bridge window [io  size 0x2000]: failed to assign
[  274.586206] pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: can't assign; no space
[  274.586210] pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: failed to assign
[  274.586214] pcieport 0000:02:01.0: bridge window [io  size 0x1000]: can't assign; no space
[  274.586217] pcieport 0000:02:01.0: bridge window [io  size 0x1000]: failed to assign
[  274.586221] pcieport 0000:02:02.0: bridge window [io  size 0x1000]: can't assign; no space
[  274.586224] pcieport 0000:02:02.0: bridge window [io  size 0x1000]: failed to assign
[  274.586230] pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: can't assign; no space
[  274.586233] pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: failed to assign
[  274.586237] pcieport 0000:02:02.0: bridge window [io  size 0x1000]: can't assign; no space
[  274.586241] pcieport 0000:02:02.0: bridge window [io  size 0x1000]: failed to assign
[  274.586244] pcieport 0000:02:01.0: bridge window [io  size 0x1000]: can't assign; no space
[  274.586248] pcieport 0000:02:01.0: bridge window [io  size 0x1000]: failed to assign

?

but after a recent update no more joy on the mouse/keyboard

/var/log/pacman.log - what was in that recent update?
Do you still have the problem w/ the LTS kernel?
Do you still have journals from before things broke? (… -b -δ)

The overall strategy will be to check what things look like when they work and contrast that w/ the status quo to understand where the significant different (ie "error") is and then address that.
Right off the bat, the bus allocation failure looks worrisome.
Try to add "pci=realloc" to the https://wiki.archlinux.org/title/Kernel_parameters

loqs · 2025-09-16 20:32:51

Do the devices work when directly connected to the laptop?

2.0.33 · 2025-09-17 18:46:00

loqs wrote:

Do the devices work when directly connected to the laptop?

yes

2.0.33 · 2025-09-17 20:30:08

Hello again,

seth wrote:

Does http://0x0.st/Kcw6.txt even have the dock attached? There's no trace...

oops, did too many boots and juggled too many files that day. Try this one http://0x0.st/Kch3.txt

seth wrote:

No concerns about...

Nope. It was all white instead of red like the "device unresponsive" message. I also found an older log where everything was still working: http://0x0.st/KchX.txt You can see my Logitech wireless mouse getting detected and it has the same "no space"-messages.
Nevertheless I tried the following kernel options:
intel_iommu=on: no improvement
pci=realloc=on: no improvement
pci=reallo=off: no improvement

also used liunx-lts: no improvement

seth wrote:

/var/log/pacman.log - what was in that recent update?

http://0x0.st/Kc7-.txt
This is a snippet of the log for that specific update. Just to be sure I don't mess up the times, if the timestamp say 16:00:00+0200 it actually means 18:00:00 localtime, correct?

Hope that gives a hind what is happening!

seth · 2025-09-17 21:17:39

Sep 14 16:16:00 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:01.0: bridge window [io  size 0x1000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:01.0: bridge window [io  size 0x1000]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [io  size 0x1000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [io  size 0x1000]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem size 0x00200000 64bit pref]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [io  size 0x1000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:02.0: bridge window [io  size 0x1000]: failed to assign
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:01.0: bridge window [io  size 0x1000]: can't assign; no space
Sep 14 16:16:00 calculus.home kernel: pcieport 0000:02:01.0: bridge window [io  size 0x1000]: failed to assign

is in the "good" journal but that also seems to only have a logitech dongle on ub 1-4 which does not look like it't the dock?

Sep 14 16:14:19 calculus.home kernel: usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
Sep 14 16:14:19 calculus.home kernel: usb 4-1.3: New USB device found, idVendor=0bda, idProduct=0411, bcdDevice= 2.03
Sep 14 16:14:19 calculus.home kernel: usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 14 16:14:19 calculus.home kernel: usb 4-1.3: Product: USB3.2 Hub
Sep 14 16:14:19 calculus.home kernel: usb 4-1.3: Manufacturer: Generic
…
Sep 14 16:14:24 calculus.home systemd-logind[442]: Lid closed.
…
Sep 14 16:14:45 calculus.home kernel: usb 1-4: new full-speed USB device number 7 using xhci_hcd
Sep 14 16:14:45 calculus.home kernel: usb 1-4: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
Sep 14 16:14:45 calculus.home kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Sep 14 16:14:45 calculus.home kernel: usb 1-4: Product: USB Receiver
Sep 14 16:14:45 calculus.home kernel: usb 1-4: Manufacturer: Logitech
Sep 14 16:14:45 calculus.home kernel: input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/0003:046D:C52B.0001/input/input17
Sep 14 16:14:45 calculus.home kernel: hid-generic 0003:046D:C52B.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-4/input0
Sep 14 16:14:45 calculus.home kernel: input: Logitech USB Receiver Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:046D:C52B.0002/input/input18
Sep 14 16:14:45 calculus.home kernel: input: Logitech USB Receiver Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:046D:C52B.0002/input/input19
Sep 14 16:14:46 calculus.home kernel: input: Logitech USB Receiver System Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:046D:C52B.0002/input/input20
Sep 14 16:14:46 calculus.home kernel: hid-generic 0003:046D:C52B.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.0-4/input1
Sep 14 16:14:46 calculus.home kernel: hid-generic 0003:046D:C52B.0003: hiddev97,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:14.0-4/input2
Sep 14 16:14:46 calculus.home mtp-probe[1370]: checking bus 1, device 7: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4"

It also only shows up only 25s after the dock was attached and the lid had been closed?
Where

Sep 17 22:12:21 calculus.home kernel: usb 4-1: Product: HP USB-C Dock G5
…
Sep 17 22:12:37 calculus.home systemd-logind[429]: Lid opened.
Sep 17 22:12:38 calculus.home kernel: pcieport 0000:02:00.0: Unable to change power state from D3hot to D0, device inaccessible

now you seem to have undocked after 16 seconds?

[2025-09-14T16:06:15+0200] [ALPM] upgraded systemd-libs (257.8-2 -> 257.9-1)
[2025-09-14T16:06:21+0200] [ALPM] upgraded hwdata (0.398-1 -> 0.399-1)
[2025-09-14T16:06:22+0200] [ALPM] upgraded systemd (257.8-2 -> 257.9-1)
[2025-09-14T16:06:31+0200] [ALPM] upgraded grub (2:2.12.r292.g73d1c959-1 -> 2:2.12.r359.g19c698d12-1)
[2025-09-14T16:06:44+0200] [ALPM] upgraded linux (6.16.4.arch1-1 -> 6.16.7.arch1-1)
[2025-09-14T16:07:02+0200] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'

If it's not the kernel the most likely trigger is systemd & hwdata

pci=realloc=on: no improvement
pci=reallo=off: no improvement

The parameter is *only* "pci=realloc"

Do you have a different keyboard/mouse (w/ a wire)?
Any explanation for why the dongle showed up late and on not what looks like the dock?

2.0.33 · 2025-09-18 19:59:16

seth wrote:

is in the "good" journal but that also seems to only have a logitech dongle on ub 1-4 which does not look like it't the dock?

Sorry for making this so complicated You are right, coming to think of it, that day I just needed to get the work done and connected mouse/keyboard directly to the laptop after they did not work with the dock straight away.

So I dug thru my logs and found an old one from May where you can see from the usb bus id that my mouse is actually connected to the dock: http://0x0.st/KTPd.txt
When I compare it to the current state it looks identical including the memory allocation errors until when it says "not responding, assume dead".

It also only shows up only 25s after the dock was attached and the lid had been closed?
Where [...]
now you seem to have undocked after 16 seconds?

For my "not working" log sample I did a fresh boot, connected to the dock and disconnected once my screens were working and I verified that mouse and keyboard were not. Then I uploaded the log. The whole process was short, because I didn"t want to have you look thru endless log files and only did the essential steps.
The 25s delay on the Sept 14th log would be explained by connecting to the dock, the xHCI calling "dead" at 16:14:08, me wondering what the hack is wrong and then connecting my equipment directly to the laptop at 16:14:45.

If it's not the kernel the most likely trigger is systemd & hwdata

The sad thing is now that we know the Sept 14 isn"'t really a good log and the only good log is from May, there were obviously many updates done in the meantime.

The parameter is *only* "pci=realloc"

According to NVIDIA and Intel my method should work and I chose it to be very explicit on what I wanted it to do. Anyhow, by now I also tried it your way, but still same behavior.

Do you have a different keyboard/mouse (w/ a wire)?

My keyboard actually is a wired keyboard, look for "cherry" in the good log from May. I only have a wireless mouse connected to the Logitech Unified Receiver, not a keyboard.

Any explanation for why the dongle showed up late and on not what looks like the dock?

As said above, was me having forgotten that I plugged in the components directly after getting annoyed that stuff wasn't working and needing things to be done. Sorry again for the confusion.

seth · 2025-09-18 21:30:09

According to NVIDIA and Intel my method should work

Indeed: https://raw.githubusercontent.com/torva … meters.txt

realloc same as realloc=on

The log from may actually has two docks?

Mai 05 15:38:37 calculus.home kernel: usb 3-1: new high-speed USB device number 2 using xhci_hcd
Mai 05 15:38:37 calculus.home kernel: usb 3-1: New USB device found, idVendor=03f0, idProduct=036b, bcdDevice= 6.11
Mai 05 15:38:37 calculus.home kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:37 calculus.home kernel: usb 3-1: Product: HP USB-C Dock G5
Mai 05 15:38:37 calculus.home kernel: usb 3-1: Manufacturer: Microchip
Mai 05 15:38:37 calculus.home kernel: usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
Mai 05 15:38:37 calculus.home kernel: usb 4-1: New USB device found, idVendor=03f0, idProduct=066b, bcdDevice= 6.11
Mai 05 15:38:37 calculus.home kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:37 calculus.home kernel: usb 4-1: Product: HP USB-C Dock G5
Mai 05 15:38:37 calculus.home kernel: usb 4-1: Manufacturer: Microchip
Mai 05 15:38:37 calculus.home kernel: usb 3-1.2: new high-speed USB device number 3 using xhci_hcd
Mai 05 15:38:38 calculus.home kernel: usb 3-1.2: New USB device found, idVendor=03f0, idProduct=056b, bcdDevice= 0.06
Mai 05 15:38:38 calculus.home kernel: usb 3-1.2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
Mai 05 15:38:38 calculus.home kernel: usb 3-1.2: Product: USB Audio
Mai 05 15:38:38 calculus.home kernel: usb 3-1.2: Manufacturer: Generic
Mai 05 15:38:38 calculus.home kernel: usb 3-1.2: SerialNumber: 201604140001
Mai 05 15:38:38 calculus.home kernel: usb 4-1.3: new SuperSpeed USB device number 3 using xhci_hcd
Mai 05 15:38:38 calculus.home kernel: usb 4-1.3: New USB device found, idVendor=0bda, idProduct=0411, bcdDevice= 2.03
Mai 05 15:38:38 calculus.home kernel: usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:38 calculus.home kernel: usb 4-1.3: Product: USB3.2 Hub
Mai 05 15:38:38 calculus.home kernel: usb 4-1.3: Manufacturer: Generic
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3: new high-speed USB device number 4 using xhci_hcd
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3: New USB device found, idVendor=0bda, idProduct=5411, bcdDevice= 2.03
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3: Product: USB2.1 Hub
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3: Manufacturer: Generic
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: new full-speed USB device number 5 using xhci_hcd
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: New USB device found, idVendor=03f0, idProduct=046b, bcdDevice= 0.00
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: Product: HP USB-C Dock G5
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: Manufacturer: HP
Mai 05 15:38:38 calculus.home kernel: usb 3-1.5: SerialNumber: 11AD1D0ACC707D050C210B00
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3.3: new low-speed USB device number 6 using xhci_hcd
Mai 05 15:38:38 calculus.home kernel: usb 3-1.3.3: New USB device found, idVendor=046a, idProduct=0023, bcdDevice= 0.32
Mai 05 15:38:39 calculus.home kernel: usb 3-1.3.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mai 05 15:38:39 calculus.home kernel: usb 3-1.3.4: new full-speed USB device number 7 using xhci_hcd
Mai 05 15:38:39 calculus.home kernel: usb 3-1.3.4: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.11
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.4: Product: USB Receiver
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.4: Manufacturer: Logitech
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.5: new high-speed USB device number 8 using xhci_hcd
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.5: New USB device found, idVendor=0bda, idProduct=1100, bcdDevice= 1.01
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.5: Product: HID Device
Mai 05 15:38:40 calculus.home kernel: usb 3-1.3.5: Manufacturer: Realtek
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: new SuperSpeed USB device number 4 using xhci_hcd
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.01
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: Product: USB 10/100/1000 LAN
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: Manufacturer: Realtek
Mai 05 15:38:41 calculus.home kernel: usb 4-1.4: SerialNumber: 000001
Mai 05 16:37:31 calculus.home kernel: usb 3-1: USB disconnect, device number 2
Mai 05 16:37:31 calculus.home kernel: usb 3-1.2: USB disconnect, device number 3
Mai 05 16:37:31 calculus.home kernel: usb 3-1.3: USB disconnect, device number 4
Mai 05 16:37:31 calculus.home kernel: usb 3-1.3.3: USB disconnect, device number 6
Mai 05 16:37:31 calculus.home kernel: usb 4-1: USB disconnect, device number 2
Mai 05 16:37:31 calculus.home kernel: usb 4-1.3: USB disconnect, device number 3
Mai 05 16:37:31 calculus.home kernel: usb 3-1.3.4: USB disconnect, device number 7
Mai 05 16:37:31 calculus.home kernel: usb 3-1.3.5: USB disconnect, device number 8
Mai 05 16:37:31 calculus.home kernel: usb 3-1.5: USB disconnect, device number 5

and the one that had the logitech dongle attached was on a different hub (3, not 4) and it seems there was even a secondary usb hub attached to that dock (might however be internal)

Mai 05 15:38:40 calculus.home kernel: cherry 0003:046A:0023.0003: input,hidraw2: USB HID v1.11 Keyboard [HID 046a:0023] on usb-0000:39:00.0-1.3.3/input0
Mai 05 15:38:40 calculus.home kernel: input: HID 046a:0023 as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb3/3-1/3-1.3/3-1.3.3/3-1.3.3:1.1/0003:046A:0023.0004/input/input28
Mai 05 15:38:40 calculus.home kernel: cherry 0003:046A:0023.0004: input,hidraw6: USB HID v1.11 Device [HID 046a:0023] on usb-0000:39:00.0-1.3.3/input1
Mai 05 15:38:40 calculus.home kernel: logitech-djreceiver 0003:046D:C52B.0007: hiddev99,hidraw4: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:39:00.0-1.3.4/input2
Mai 05 15:38:41 calculus.home kernel: input: Logitech Wireless Device PID:406a Keyboard as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/0000:02:02.0/0000:39:00.0/usb3/3-1/3-1.3/3-1.3.4/3-1.3.4:1.2/0003:046D:C52B.0007/0003:046D:406A.0009/input/input29

2.0.33 · 2025-09-19 15:40:58

seth wrote:

The log from may actually has two docks?

You mean as in two docking stations connected to the laptop? Because it creates USB bus 3 and 4? No, I only have one dock, and that dock has no additional hub attached to it, only a wired keyboard, the Logitech wireless receiver, ethernet cable, and two display port monitors plugged in. Pretty standard. It also has an unused USB-C port in the front, I guess that is why it creates all these different hubs with different speeds and sound outputs and what not.

To me the good and bad log look very similar until the bad one just says

Sep 17 22:12:10 calculus.home kernel: xhci_hcd 0000:39:00.0: xHCI host controller not responding, assume dead
Sep 17 22:12:10 calculus.home kernel: xhci_hcd 0000:39:00.0: HC died; cleaning up

So I wonder if there is a way to get more info from that xhci component, why exactly it failed (was a timeout or retry counter decreased in a recent version or something like this). Does it use an external firmware that was "updated"? Are there any kernel parameters to try?

seth · 2025-09-19 16:16:07

To me the good and bad log look very similar

The "good" journal has the same kind of dock simultaneously showing up on usb 3-1 and usb 4-1 and the keyboard is (only) on 3-1.3.3
The "bad" journal has the dock only showing up on usb 4-1

Have you tried to downgrade the kernel to 6.14.4-arch1-2 (the one from may, also install the LTS one - the 6.14 kernel will most likely still boot but you want an insurance)
You can in doubt fetch the old kernel from the https://wiki.archlinux.org/title/Arch_Linux_Archive

2.0.33 · 2025-09-19 18:53:43

I think this is the 5th kernel I tried
6.14.4: http://0x0.st/KTwz.txt

seth · 2025-09-19 18:59:27

So same as current kernel - have you tried to connect the dock to another usb port?
There has to be a reason why it showed the different behavior in may…

2.0.33 · 2025-09-19 19:52:30

seth wrote:

So same as current kernel - have you tried to connect the dock to another usb port?

I cannot connect it to a different port, because my T470s has only one USB-C port.

Out of interest I made a log of my other laptop (which works), https://0x0.st/KTwG.log

Surprisingly, it also shows an "assumed dead" error. And some others that are not present with my main laptop,

Sep 19 20:38:35 algebra kernel: usbcore: registered new interface driver usbhid
Sep 19 20:38:35 algebra kernel: usbhid: USB HID core driver
Sep 19 20:38:35 algebra kernel: usb 1-5.3.3: new low-speed USB device number 10 using xhci_hcd
Sep 19 20:38:35 algebra kernel: usb 1-5: USB disconnect, device number 7
Sep 19 20:38:36 algebra kernel: usb 1-5.2: USB disconnect, device number 8
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 2:1: cannot set freq 48000 to ep 0x4
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 3:0: failed to get current value for ch 0 (-22)
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 3:0: cannot get min/max values for control 2 (id 3)
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 4:0: failed to get current value for ch 0 (-22)
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 16:0: failed to get current value for ch 0 (-22)
Sep 19 20:38:36 algebra kernel: usb 1-5.2: 16:0: cannot get min/max values for control 2 (id 16)

,yet in the end I can use all my peripherals.

Yes, what can be different between now and then? That brings me back to the question of firmware. As I understand it, there is a repository of firmwares that the manufacturers update. But to actually use it it also has to be updated by the OS. My main laptop is up to date, my other laptop has not been updated in a while, actually saying there is new firmware available. Is this xHCI dependent on external firmware? That might be the difference between now and then.

seth · 2025-09-19 20:05:34

Additionally

Sep 19 20:38:47 algebra kernel: usb 4-1: Product: HP USB-C Dock G5

so the double entries are normal and to be expected.

It's not

Mai 05 12:03:26 calculus.home kernel: DMI: LENOVO 20JSS01400/20JSS01400, BIOS N1WET75W (1.54 ) 07/26/2024
Sep 19 20:30:58 calculus.home kernel: DMI: LENOVO 20JSS01400/20JSS01400, BIOS N1WET75W (1.54 ) 07/26/2024

https://archlinux.org/packages/core/any … are-intel/ - but I don't think there's firmware for the xhci controller

Does the dock respond when you're only booting the multi-user.target?

mmy8x · 2025-09-20 05:40:04

This looks like some thunderbolt stuff, I'm not very familiar with that. I don't even know if this xHCI controller is something in the dock or in the laptops?

Your other laptop appears to be using USB 2.0 passthrough scheme, where USB 2.0 devices in the dock are routed to port 1-5 of the main xHCI controller on the motherboard. That's why they work even when the TB xHCI controller acts up.

In the log from May, they were showing up on port 3-1 under the TB xHCI controller.

Now you apparently tried the same 6.14.4-arch1-2 kernel binary built in April and it isn't working, looks like the xHCI PCIe device disappears for a moment? IDK if any firmware package has any effect on TB. AFAIK these TB controllers have firmware in nonvolatile memories, but IDK whether Arch would update it or not. Perhaps Windows did?

It is normal that a USB 3.x hub shows up both as a SuperSpeed hub and a high-speed hub. These are practically separate buses running on separate wires and hubs are separate too from host's point of view.

mmy8x · 2025-09-20 08:44:57

Answering to myself, there is no Thunderbolt in this dock, it's just an ordinary USB-C hub with DisplayPort alt mode and Power Delivery.
https://dancharblog.wordpress.com/2021/ … -teardown/

So the misbehaving 8086:15c1 PCIe device (Intel JHL6240?) is in the laptop. Still no idea what broke it, any BIOS updates?

I wonder what happens if you connect any other random USB 1.1/2.0 device to the type C port, either one with native C plug, or using a passive C→A adapter or a type C hub?

seth · 2025-09-20 14:23:19

See #14, BIOS is the same version.
It could however be a BIOS configuration change (legacy modes, permanent power supply/offline charging, de/activated hardware like webcam, bluetooth, …) though I'd first test the behavior w/ the multi-user.target to avoid weird power supply issues (GPU demand by the compositor, powerdevil, …)

2.0.33 · 2025-09-20 18:12:03

seth wrote:

though I'd first test the behavior w/ the multi-user.target

available here http://0x0.st/KTGF.txt

2.0.33 · 2025-09-20 18:27:14

mmy8x wrote:

Still no idea what broke it, any BIOS updates?

My BIOS is from 2024, so no update between May (working) and now (not working).

mmy8x wrote:

I wonder what happens if you connect any other random USB 1.1/2.0 device to the type C port, either one with native C plug, or using a passive C→A adapter or a type C hub?

I don't have too many USB-C devices, but I connected my iPhone and my digital camera to that one USB-C port I have on this laptop. All working fine, could access my photos on both devices. I do not own a USB-A to USB-C adapter. My household is old school

seth · 2025-09-20 21:02:26

Well, it's not the user session.

It's not the kernel.
It's not the BIOS (settings, though??)

Sep 20 20:00:15 calculus.home kernel: pcieport 0000:01:00.0: Assigned bridge window [mem 0xb0000000-0xd1ffffff 64bit pref] to [bus 02-39] cannot fit 0x200000 required for 0000:02:02.0 bridging to [bus 39]
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem 0x00000000 64bit pref] to [bus 39] requires relaxed alignment rules
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 39] add_size 200000 add_align 100000
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-39] add_size 2000
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: failed to assign
Sep 20 20:00:15 calculus.home kernel: pcieport 0000:01:00.0: bridge window [io  size 0x2000]: can't assign; no space

seems to no have caused any harm in May and also shows up on the other system - I still don't like that.
Can you flip rebar support in the BIOS?

Then there's

Sep 20 19:59:03 calculus.home kernel: ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
Sep 20 19:59:03 calculus.home kernel: acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
Sep 20 20:00:10 calculus.home kernel: pcieport 0000:02:02.0: ASPM: current common clock configuration is inconsistent, reconfiguring

Try to add "pcie_aspm=off" to the kernel parameters.

Does it help to rescan the PCI bus after attaching the journal?
https://stackoverflow.com/questions/323 … f-pcie-bus

2.0.33 · 2025-09-20 21:08:07

seth wrote:

It's not the BIOS (settings, though??)

Which would you like to know or have me set/change?

seth · 2025-09-20 21:20:01

No, the question is whether you maybe changed something there.

mmy8x · 2025-09-21 08:35:26

2.0.33 wrote:

I don't have too many USB-C devices, but I connected my iPhone and my digital camera to that one USB-C port I have on this laptop. All working fine, could access my photos on both devices. I do not own a USB-A to USB-C adapter. My household is old school

Are these devices high-speed or SuperSpeed?
Any differences in 'dmesg -W' output compared to the dock?

2.0.33 wrote:

Out of interest I made a log of my other laptop (which works), https://0x0.st/KTwG.log

The high-speed part of the dock (usb 1-5) connects at 20:38:34, disconnects at 20:38:35, connects again at 20:38:36. Perhaps it's same thing with SuperSpeed part and that's why the TB xHCI controller is cycling on and off? (It seems to be turning off with no devices connected).

Do you have logs from that other laptop? Was this behavior always there?
Could it be something completely stupid like having vs not having external power applied to the dock?

Last edited by mmy8x (2025-09-21 08:37:13)

2.0.33 · 2025-09-21 12:27:06

seth wrote:

No, the question is whether you maybe changed something there.

I do not remember everything I did between May and now BUT it is very unlikely. I went from Tinkerer 20 years ago to User these days. If things work I usually don't touch them (at least on this level) and so far the Arch experience was smooth sailing. So smooth, actually that I even installed it on my (then Windows) gaming PC for some Steam/Proton action. (pretty happy btw). so, pretty sure I did not touch the BIOS in the last half year.

pcie_aspm=off

no dice, http://0x0.st/KTCs.log

2.0.33 · 2025-09-21 12:42:46

Are these devices high-speed or SuperSpeed?
Any differences in 'dmesg -W' output compared to the dock?

I dmesg'ed a direct connection of my iPhone, it is a high-speed device, http://0x0.st/KTFD.log
It also has these "no space" messages, but obviously not the "assume dead" error.

Do you have logs from that other laptop? Was this behavior always there?

I posted a log of my working laptop a bit further up. Here it is again, http://0x0.st/KTwG.log
Not sure how I should answer the question. In that log it finds USB devices 7 and 8, only to remove them again a few lines further down. I'd say no, I see 3x HP G5 entries, one for each full-speed, high-speed, and super-speed hub that it provides.

Could it be something completely stupid like having vs not having external power applied to the dock?

For sure not the power. I mean the same setup works with my other Linux laptop, as well as with my Windows 11 one from work, which I use quite regularly with this setup.

Arch Linux

#1 2025-09-16 19:39:25

[SOLVED] keyboard/mouse at dock not working anymore after update

#2 2025-09-16 20:10:14

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#3 2025-09-16 20:32:51

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#4 2025-09-17 18:46:00

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#5 2025-09-17 20:30:08

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#6 2025-09-17 21:17:39

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#7 2025-09-18 19:59:16

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#8 2025-09-18 21:30:09

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#9 2025-09-19 15:40:58

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#10 2025-09-19 16:16:07

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#11 2025-09-19 18:53:43

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#12 2025-09-19 18:59:27

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#13 2025-09-19 19:52:30

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#14 2025-09-19 20:05:34

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#15 2025-09-20 05:40:04

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#16 2025-09-20 08:44:57

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#17 2025-09-20 14:23:19

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#18 2025-09-20 18:12:03

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#19 2025-09-20 18:27:14

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#20 2025-09-20 21:02:26

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#21 2025-09-20 21:08:07

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#22 2025-09-20 21:20:01

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#23 2025-09-21 08:35:26

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#24 2025-09-21 12:27:06

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

#25 2025-09-21 12:42:46

Re: [SOLVED] keyboard/mouse at dock not working anymore after update

Board footer