You are not logged in.
Did you actually check that at some point?
yes. There aren't really too many options on a Thinkpad this old. I changed all the USB and charging modes I have, some Wake on Lan via Dock, disabled Wake by Thunderbolt and disabled Thunderbolt and USB devices in Pre Boot Enviornment. I tried it with AC connected and disconnected, still no joy in any constellation
You could also try the arch installation iso and the dock on the other notebook and a live version of Pop!OS on the currently affected one…
I trued the Pop_OS iso with the bad laptop, but it did not work. But then my working laptop obviously has seen some updates over the years, to the 22.04 LTS is not in its vanilla state anymore.
Offline
But these Thunderbolt controllers have their FW too and I wouldn't be surprised if it's a separate flash chip which can be updated separately. And the dock may have FW.
The dock for sure has FW, as I updated it in the past.
IMO there are three viable approaches:
0. If you haven't already, try a "full power cycle": disconnect all power sources and the battery for a minute. Technically there is likely still an RTC battery, but hopefully it isn't used to maintain any state in the TBT controller.
did that, did not change anything
1. Check if the "HC died" is triggered by powering root hub ports on or merely a coincidence.
How would I do that?
Offline
I trued the Pop_OS iso with the bad laptop, but it did not work. But then my working laptop obviously has seen some updates over the years, to the 22.04 LTS is not in its vanilla state anymore.
Does the arch install iso work w/ the dock on the other laptop?
How would I do that?
I assume the idea is just to
echo 'on' | sudo tee /sys/bus/usb/devices/usbX/power/control
for the relevant usbX
Offline
1. Check if the "HC died" is triggered by powering root hub ports on or merely a coincidence.
How would I do that?
I looked at it and TBH I can't see how this could be the trigger. But no harm trying at this point, I guess?
Dynamic debug needs to be enabled to see the new message, which is a good idea in such cases anyway.
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index b3a59ce1b3f4..f2329812349c 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -655,6 +655,11 @@ static void xhci_set_port_power(struct xhci_hcd *xhci, struct xhci_port *port,
xhci_dbg(xhci, "set port power %d-%d %s, portsc: 0x%x\n",
hcd->self.busnum, port->hcd_portnum + 1, on ? "ON" : "OFF", temp);
+ if (hcd->self.busnum == 4) {
+ xhci_dbg(xhci, "set port power bus 4 ignored\n");
+ return;
+ }
+
temp = xhci_port_state_to_neutral(temp);
if (on) {
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index defd878f7649..152766ce9d39 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1384,6 +1384,7 @@ void xhci_hc_died(struct xhci_hcd *xhci)
if (notify)
xhci_err(xhci, "xHCI host controller not responding, assume dead\n");
xhci->xhc_state |= XHCI_STATE_DYING;
+ dump_stack();
xhci_cleanup_command_queue(xhci);
Offline
Does the arch install iso work w/ the dock on the other laptop?
Interesting. I get an "assume dead" message, but the dock still work. Only checked the keyboad as I am on the console, but seems to work fine
Offline
But no harm trying at this point, I guess?
Guess not. I however cannot make anything of that gibberish
Offline
The gibberish tells us that even though writing the PORTSC register is the last action (at least out of those which are logged) that happens before "HC died", if we skip writing this register, it still dies a moment later. So it wasn't the cause or even a contributing factor.
Unfortunately this means we have no idea what the problem is and whether kernel actions have anything to do with it. And they quite possibly don't, because you tried old kernels which used to work and now they are no different from current kernels.
The "HC died" may simply be a matter of the TBT xHCI turning itself off because it believes no devices are connected. Which is either because the dock disconnects itself for a moment, or because the xHCI HW/FW is buggy.
Then it comes back, but only detects the SuperSpeed part of the dock. Again, either the xHCI is buggy, or the dock is buggy and really doesn't reconnect its USB2 part.
I have an adapter here which splits a USB 3.0 port into separate SuperSpeed-only and USB2-only ports. With such a gadget and/or an inverse adapter which splits the dock's connection into separate 3.0/2.0 plugs, it would be possible to experiment a little and maybe find it out. But otherwise I'm out of ideas.
You said you tried disabling autosuspend, so it isn't that either.
edit:
Or maybe one idea. What if you disable/enable bus 3 port 1, which is where the USB2 dock used to be? Or same thing on bus 4 (honestly, this will disconnect the dock and the xHCI will probably turn itself off again)?
echo 1 > /sys/bus/usb/devices/3-0\:1.0/usb3-port1/disable
echo 0 > /sys/bus/usb/devices/3-0\:1.0/usb3-port1/disable
Or do you have / can you have Windows on this laptop? Would the dock work with it? If not, go straight to HP customer support...
Last edited by mmy8x (2025-10-15 20:23:03)
Offline
What if you disable/enable bus 3 port 1, which is where the USB2 dock used to be? Or same thing on bus 4 (honestly, this will disconnect the dock and the xHCI will probably turn itself off again)?
Does nothing in terms of peripherals and, as you said, disconnects and reconnects part of the dock when done with USB4.
http://0x0.st/KQP3.txt
Or do you have / can you have Windows on this laptop? Would the dock work with it? If not, go straight to HP customer support...
No, I don't and I will not install it. I guess this is one of those issues the will remain unsolved until, as suddenly as it appeared, will disappear as well when HP changes something on their firmware again. HP will not give a hoot about Linux, because officially the dock is only supported by ChromeOS (and Win/Mac).
Offline
ChromeOS uses a linux kernel, though… can't you explicitly downgrade the docks firmware?
Offline