As a last note, I wonder if this issue may be somehow related to other PD problems people are seeing…
I think you have done it already but have you tried to plugin the cable directly to the FW16 without a USB-C module?
Yes, I tried it as well with no difference.
At first I was assuming some interference / signal degradation that was affecting link training and causing the downgrade, so removing the module seemed like a natural thing to try. But since it failed and as I learned more about Thunderbolt debugging I realized that the problem is rather located on the capabilities discovery (unless those two are bond together and I’m not aware of it yet).
Do you know of any Software for Windows to check it? I would like to know it myself.
I have TB3 and TB4 docks and don’t know if they run full speed or switch to USB-C
Good question, I guess that plenty of users may not realize that their Thunderbolt peripherals falls back to the slower speed.
I don’t have Windows myself, but I can already see that it’s not trivial to find info regarding Thunderbolt link speed. The usual approach of “let’s not make the user think too much and assume the best” applies here with all of its power. There’s a way to check the PCIE link bandwidth, but I’m afraid that it may not directly reflect the link speed - PCIE is tunneled, lives on a different layer of communication, I can imagine it may negotiate full x4 speed while Thunderbolt link still remains the bottleneck.
I’ll look around and get back to you (and anyone else interested).
Quick update, without investigation details yet (I have quite some material for everyone interested in some deeper-diving).
I educated myself a bit about how UCSI works and how acpi_ucsi driver works. Quick overview of the internal state and I know for sure that returned cable capabilities seem to be kinda “default”? As 10Gbps poor passive cable. Also triggering the UCSI command that reads cable props doesn’t really induce any CC1/CC2 transmission, so I guess it’s all cached by EC.
I turned my focus into EC now, trying to understand how the Cypress PD controllers works and whether the communication order is compliant with the spec. Or whether Framework calls for the TBT capabilities at all and if so - when and what conditions it.
1 Like
There’s a new development. Up until now I tried multiple passive cables, all of them at least TB4 certified with length of 0.8m or 0.5m. Authenticity was confirmed with e-marker reader. None of them allowed to negotiate 40Gbps, apart of one single, very random time I mentioned above.
Now, however, I decided to give it a try to an active cable. It’s not convenient for me given how close the eGPU is to my laptop, but hey it works. Reproducible every time, 2*20Gbps negotiation succeeds without a problem.
I still hope this is a firmware-fixable problem, not signal-integrity one. It seems though that in certain cases Framework is having a serious issues with negotiating full Thunderbolt speeds on passive cables.
I also updated my github case with the newest findings and dumps of TB registers: Framework 16 doesn't query Thunderbolt cable capabilities and falls back to 20Gbps · Issue #56 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
In case anyone missed my github comment - the problem was resolved with firmware upgrade to 4.x branch (PD fw got updated to 0.0.21 IIRC). It is negotiating 40Gbps reliably now for any kind of cable.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.