Unfortunately it still panics – I’ve posted on gitlab.
Dang ok, it’s slightly different then unfortunately.
I also opened another issue related a single display not working either (no kernel panic though).
I also get crashes just when disconnecting two 4K monitors (which were connected directly into the laptop USB-C ports). Overall the experience is extremely rough so far if you want to take advantage of those ports, to the point where I’m considering buying an Intel mainboard. Hopefully things will be fixed in due time though…
My system still freezes when booting up while connected to the dock, right around when GNOME is supposed to launch. The same thing happens when shutting down.
Framework 13, AMD Ryzen 7840U, Fedora 39.
Dock: CalDigit TS4
Have you run the beta BIOS update recently?
No issues for mine when plugging into OWC thunderbolt hubs (real docks use real hardware docking mechanisms imho) or an Anker hub. Same distro, most recent kernel.
Framework 13 AMD Ryzen 7040 BIOS 3.03b BETA
Following up/“answering” on my previous post about my monitor issues with the Kensington SD5780T dock and monitor connected to it over HDMI:
I finally got my hands on a second, Apple, TB4 cable. Just replacing the host/dock cable with this Apple cable didn’t fix the issue:
[FW]---(Apple TB4 cable)---[dock]---(HDMI cable)---[monitor]
So I switched back to the Kensington-supplied TB4 cable.
Then, on a whim since I now have a second TB4 cable around I used one of the dock’s TB outputs to connect to the monitor’s USB-C (DP alt mode) input instead of HDMI:
[FW]---(Kensington TB4 cable)---[dock]---(Apple TB4 cable)---[monitor]
and to some surprise the monitor (EDID) gets detected correctly and everything (display-wise) works.
This does make the Linux kworker issue, or rather its workaround of toggling power to the dock, have more of an “impact” with various windows scurrying off to the laptop monitor, as expected.
Anyway, for extra kicks I also tried:
[FW]---(Apple TB4 cable)---[dock]---(Kensington TB4 cable)---[monitor]
And that, consistently, results in a new failure mode: The monitor is detected but only at 30Hz. Not enough bandwidth?
Anyway, the Kensington cable seems to be at least part of the problem - on the AMD USB4 host - The same first/original topology above still works with many other laptops including a gen11 Intel FW.
Hey there, just adding my feedback to this issue.
I just got a CalDigit TS4 dock for my Framework 16 (no dGPU) and I noticed a really weird behavior with monitor resolutions.
When running on Windows 11, I can connect 2 monitors in DisplayPort (one using the DP port and the other through an USB-C to DP cable) on the dock and they both work perfectly at high resolution and refresh rate (1440p 165Hz).
But under Linux (Arch, Wayland/Hyprland) it seems that the displays can’t report their EDID infos correctly because they are locked at 640x480 60Hz and no display infos can be seen.
Although I can force the two monitors to their full resolution (but not above 120Hz) through hyprctl commands.
Would this be a bug in the AMD driver in Linux?
There should be enough logging in TB/USB4 drivers to be enabled to see them choosing DP connection speeds etc. I think that should be the only other way to possibly cause issues not rooted in the GPU drivers when you can still get some connections to work.
On windows with the software connection manager it reports the DP capabilities of the outputting TB controller for every tunnel and what it ended up choosing (Windows event log). And maybe with linux you can actually see the math of it blocking a specific DP speed because it thinks it is out of bandwidth or sth.
Maybe this can narrow it down to one or the other. Or a surprise 3rd participant in those negotiations.
What’s the best way to collect logs for a quality bug report, with regards to thunderbolt dock issues?
It seems everybody is experiencing their own unique paper cuts with TB docks. In my case, everything works great with my AMD 13", running fedora 39, connected to a Caldigit TS3+, except that on wake from sleep, all usb is dead until I unplug and replug. My display, which is connected over display port, works fine on wake. But my keyboard and mouse are dead until I pull and replug the cable.
Figure this is more likely something to report to Fedora’s bugtracker than Framework’s, but I don’t know enough about linux logging to know how to find good logs to include in the report.
Is it still working well? Are you able to do updates through LVFS?
https://fwupd.org/lvfs/docs/users
Hello, new friends!
I have a Framework Laptop 13 (AMD Ryzen 7040 Series) Professional Pre-Built on order (with Windows 11 Pro, the OS I intend to use), and I want to get a dock for it. I’m looking at this one:
Plugable 12-in-1 USB C Docking Station Triple Monitor
https://www.amazon.com/gp/product/B09NQQ1G1N
I’m no hardware maven, but I note that the laptop’s power adapter is rated 65W and this dock only passes on 60W to the laptop. Will that be a problem?
Anyone have experience with this dock? I do intend to run three monitors, but only need 1920x1080 resolution out of them.
Anybody care to suggest a better dock choice?
Many thanks!
Rob (in Toronto)
Those of you who have posted that docks work inconsistently or with different cables can you please experiment with stopping fwupd.service before you plug in the dock after boot up?
If that helps there is an upstream fwupd bug about what might be going on.
1 Like
I can confirm that stopping fwupd.service didn’t change anything for my monitor issue, using both DP and USB-C to DP cables on a CalDigit TS4 dock. I commented on the GitLab issue above the other day.
Although I’ve been able to test out with 2 other DP monitors (a iiyama 1080p 75Hz and a LG 1080p 21:9 75Hz) and they are recognized correctly. I have a different (LG) 1440p 165Hz display I can try tomorrow too but I’m starting to think it’s linked to high-spec (recent ?) monitors.
I also just tested using a USB-C to HDMI cable I had on hand and my ASUS monitor gets detected perfectly with EDID at up to 1440p 144Hz (which is expected in HDMI).
EDIT: After testing with the LG 1440p 165Hz monitor (LG Ultragear 27GR75Q-B), it surprisingly works perfectly despite being very similar to the ASUS one(s)…
I’ll include the monitor EDID and update my comment over GitLab hopping it can help diagnose the issue over Linux as it strangely works on Windows 
LG EDID
edid-decode (hex):
00 ff ff ff ff ff ff 00 1e 6d 4d 5c 33 6c 06 00
04 21 01 04 b5 3c 22 78 9d 8c b5 af 4f 43 ab 26
0e 50 54 21 08 00 d1 c0 61 40 01 01 01 01 01 01
01 01 01 01 01 01 09 ec 00 a0 a0 a0 67 50 30 20
3a 00 58 54 21 00 00 1a 00 00 00 fd 0c 30 a5 03
03 46 01 0a 20 20 20 20 20 20 00 00 00 fc 00 4c
47 20 55 4c 54 52 41 47 45 41 52 0a 00 00 00 ff
00 33 30 34 4e 54 43 5a 43 43 39 31 35 0a 02 17
02 03 31 71 23 09 06 07 e2 00 6a 83 01 00 00 e3
05 c0 00 e6 06 05 01 53 53 2e 48 10 04 03 01 1f
13 3f 40 6d 1a 00 00 02 05 30 a5 00 04 53 2e 53
2e 56 5e 00 a0 a0 a0 29 50 30 20 35 00 58 54 21
00 00 1a 5a a0 00 a0 a0 a0 46 50 30 20 3a 00 58
54 21 00 00 00 6f c2 00 a0 a0 a0 55 50 30 20 3a
00 58 54 21 00 00 1a 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
70 12 79 03 00 03 00 14 3d 11 01 84 ff 09 9f 00
2f 80 1f 00 9f 05 76 00 02 00 04 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 90
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: GSM
Model: 23629
Serial Number: 420915 (0x00066c33)
Made in: week 4 of 2023
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 10
DisplayPort interface
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Standby
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
Default (sRGB) color space is primary color space
First detailed timing does not include the native pixel format and preferred refresh rate
Display supports continuous frequencies
Color Characteristics:
Red : 0.6855, 0.3085
Green: 0.2646, 0.6679
Blue : 0.1503, 0.0576
White: 0.3134, 0.3291
Established Timings I & II:
DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
Standard Timings:
DMT 0x52: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
Detailed Timing Descriptors:
DTD 1: 2560x1440 143.973257 Hz 16:9 222.151 kHz 604.250000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 90 Vpol N
Display Range Limits:
Monitor ranges (Range Limits Only): 48-165 Hz V, 258-258 kHz H, max dotclock 700 MHz
Display Product Name: ‘LG ULTRAGEAR’
Display Product Serial Number: ‘304NTCZCC915’
Extension blocks: 2
Checksum: 0x17
Block 1, CTA-861 Extension Block:
Revision: 3
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
Native detailed modes: 1
Audio Data Block:
Linear PCM:
Max channels: 2
Supported sample rates (kHz): 48 44.1
Supported sample sizes (bits): 24 20 16
Video Capability Data Block:
YCbCr quantization: No Data
RGB quantization: Selectable (via AVI Q)
PT scan behavior: Always Underscanned
IT scan behavior: Always Underscanned
CE scan behavior: Always Underscanned
Speaker Allocation Data Block:
FL/FR - Front Left/Right
Colorimetry Data Block:
BT2020YCC
BT2020RGB
HDR Static Metadata Data Block:
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Supported static metadata descriptors:
Static metadata type 1
Desired content max luminance: 83 (301.833 cd/m^2)
Desired content max frame-average luminance: 83 (301.833 cd/m^2)
Desired content min luminance: 46 (0.098 cd/m^2)
Video Data Block:
VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
VIC 3: 720x480 59.940060 Hz 16:9 31.469 kHz 27.000000 MHz
VIC 1: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz 148.500000 MHz
VIC 19: 1280x720 50.000000 Hz 16:9 37.500 kHz 74.250000 MHz
VIC 63: 1920x1080 120.000000 Hz 16:9 135.000 kHz 297.000000 MHz
VIC 64: 1920x1080 100.000000 Hz 16:9 112.500 kHz 297.000000 MHz
Vendor-Specific Data Block (AMD), OUI 00-00-1A:
Version: 2.5
Minimum Refresh Rate: 48 Hz
Maximum Refresh Rate: 165 Hz
Flags 1.x: 0x00
Flags 2.x: 0x04
Maximum luminance: 83 (301.833 cd/m^2)
Minimum luminance: 46 (0.098 cd/m^2)
Maximum luminance (without local dimming): 83 (301.833 cd/m^2)
Minimum luminance (without local dimming): 46 (0.098 cd/m^2)
Detailed Timing Descriptors:
DTD 2: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 33 Vpol N
DTD 3: 2560x1440 99.946436 Hz 16:9 150.919 kHz 410.500000 MHz (analog composite, sync-on-green, 600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol N
Vfront 3 Vsync 10 Vback 57 Vpol N
DTD 4: 2560x1440 119.997589 Hz 16:9 182.996 kHz 497.750000 MHz (600 mm x 340 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 72 Vpol N
Checksum: 0x01 Unused space in Extension Block: 24 bytes
Block 2, DisplayID Extension Block:
Version: 1.2
Extension Count: 0
Display Product Type: Standalone display device
Video Timing Modes Type 1 - Detailed Timings Data Block:
DTD: 2560x1440 164.957741 Hz 16:9 257.169 kHz 699.500000 MHz (aspect 16:9, no 3D stereo, preferred)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 111 Vpol N
Checksum: 0xf3
Checksum: 0x90
@Alex_S: I keep using it 3 days a week at work without any issues😊
Not sure if I mentioned it already, but I disable the Frameworks internal display and work only on the 2 external 1440p monitors.
I did not try to update the dock with LVFS, as it works just fine.
I’m also using stock ubuntu 22.04 with 6.5 kernel (not OEM). Booting from an external USB-C M.2 drive. Surprisingly also no problems here.
(Private use is with Arch Linux - but that never gets connected to the docking station)
Today at work I checked for updates with LVFS, and indeed there is one available:
Hope that answers your question.
PS: The update itself also worked fine
1 Like
Yes, I’ve updated everything and have retested today.
OS: Fedora 39
Kernel: 6.8.8-200.fc39.x86_64
Bios: 03.05
Dock: CalDigit TS4
I’m still getting a freeze right around the time gnome is starting or shutting down. So I have to undock before I want to boot/shutdown.
I did not try the patch mentioned here because I don’t have the time: Dock Compatibility (AMD) - USB-C / Thunderbolt - #38 by Mario_Limonciello
On another note, @Matt_Hartley have you tested running Bluefin on your FW13 and plugged it into any of the hubs/docks suggested here? Wonder how that compatibility is fairing.
Hmm…Fedora 40?
Installed Fedora 40. Same problem.
@Alex_S Docks are the bane of my existence. lol
As a hard and fast rule, generally, ANKER stuff is solid (usually). I’d connect them to the higher power consuming ports, through. Pushing webcams, USB headsets or external drives is fine.
-
Don’t run video through your dock. Use HDMI or DP expansion cards as we control that narrative and we do not for docks. Most issues we see are folks pushing HDMI or DP through a dock, we have no control there and it rarely works.
-
And to avoid another common issue, use DP to DP expansion card or HDMI to HDMI expansion card, do not use adapters.
2 Likes