Just for clarity - TBT4 isn’t an alt mode that is negotiated. Usb4 is the alt mode that negotiates. Tbt4 is a branding for USB4 that supports a specific set of speeds and features.
But nonetheless I agree this certainly sounds like a failure for the PD negotiation. You guys don’t happen to have access to a PD analyzer do you? Something like Total Phase?
Even though it might be a problem only showing up with some cables, the real problem might be in the dock itself.
This is the kind of situation that it makes sense to analyze which component in the chain is behaving out of spec.
It’s fairly infuriating, and often takes numerous power cycles of the dock before it settles down. The only thing keeping me sane is knowing there are other people working on it.
I’m using the 1m cable that came with the dock, and I don’t have any other cables to test. I might try purchasing a different (shorter) cable to see if it makes a difference.
EDIT: Now that I’ve re-read @Gabriel_Tremblay’s comments, it seems that the purpose of a different cable would be to avoid TB4, but that doesn’t fit my use-case, so I’ll hold off on buying something.
Oh, interesting. I wonder if the fault is in the dock, in the laptop, or in Linux. It seems relevant that the problem didn’t start showing up until late in the 6.6.x kernel series? But if the problem is in the dock, I’d like to look into replacing it with something different.
For my use case (machine docked almost all the time, external monitor) this kworker/interrupt issue isn’t too big a deal, although I’d like to see it resolved.
Getting dock-connected monitors (in my case using the dock’s HDMI output) to work would be a little more interesting, so I can retire the extra cable that’s protruding from the other side of the laptop. This is far more miss than hit on the Linux side, and so far I haven’t seen any traction upstream.
(Note that the exact dock/monitor/cable combo works with an 11th gen FW laptop, and also with a M1 Mac Pro).
So, I’m holding off on swapping out the dock until there’s some clarity on that front. I’d prefer not to throw parts at the problem anyway.
It could be that these issues share a root cause.
Anyway, let’s keep this thread focused on tracking down these stray interrupts/kworker CPU cycles. There are other threads here that cover the dock-connected monitor issue on Linux.
I disconnect and reconnect multiple times per day.
This is news to me. My 4K monitor works great connected to my dock (I use the one TB4 cable for everything) but I’ll have to look for the other threads you mentioned, just to be aware.
I have an Anker 778 Thunderbolt 4 dock plugged in to my FW AMD 13 running Fedora 6.8.4-200. I was having the same kworkers issue so I’ve been watching this thread.
Yesterday I updated the dock firmware from v1.23 to the latest version (1.78 I think). And after 24 hours of frequent sleep / suspends (without rebooting) I have had no issues.
Unfortunately Anker does not supply a change log, so I’m not sure what issues the firmware addressed.
More info:
I have an HDMI monitor, USB scanner and USB microstreamer plugged in to the dock.
I had to boot in to Windows and run the Anker Dockmanager app (dockmanager download - Anker US). They have a Windows and Mac version, but no Linux version that I could find.
@Matt_Hartley as discussed on support thread some time ago, I finally opened a Fedora bug and tagged you there.
As mentioned in the bug thread I have perf data but would appreciate any insights on whether it is safe to upload to a public forum. As far as I can tell it’s just counts and stack traces, no actual data, but I haven’t used perf before so expert input is very welcome on this.
