Compatibility report (TLDR: good) between the Dell U4025QW

[Nicolas_Masse]

Hello !

I recently bought the Ultra Wide screen (Dell U4025QW). At the time of purchase I had trouble finding compatibility information of this screen with my Framework Laptop 13 AMD Ryzen 7040 and Linux. So, I thought it would help other people to give a compatibility report.

This screen is a bit special since it is connected with the laptop through Thunderbolt-4. And the Framework Laptop 13 AMD has only USB4. USB4 is in theory compatible with Thunderbolt-3 and Thunderbolt-4 is backward compatible with Thunderbolt-3. So, I took the risk and ordered one.

The screen provides power and acts as a hub to connect the USB ports, speakers & network to the laptop.

I’m running Fedora Linux 39 (at the time of writing, with kernel 6.8.4-300.fc40).

The good

• I’m using this screen at 5120x2160 60Hz on Linux every day and it works.
• the speakers work out of the box too. Just choose “Rembrandt Radeon High Definition Audio Controller” as the output device.
• the 2.5G network controller is recognized under Linux as a USB device (Realtek RTL8152) and is working.
• power delivery to the laptop is working too

The not so good

If I start or stop my laptop with the screen attached, Fedora Linux seems to have issues while switching from a Wayland session to the Console and vice versa. This was systematic with the original kernel from Fedora 39 and is less frequent with the kernel of Fedora 40 but still annoying.

→ Workaround: Boot the laptop, then plug the screen or power-on the screen. Act in reverse for powering down.

Oddly, infrequently when I plug the screen, the USB devices and the power are delivered to the laptop but the laptop does not detect any display attached.

→ Workaround: disconnect/reconnect the cable solves the issue.

Daisy-chaining another USB-C Alt-DP display (Lenovo Thinkvision M14t) using the Thunderbolt 4 downstream port of the screen did not work, though.

→ Workaround: connect the second screen to the laptop directly.

When connected all day long, I observe non-negligible CPU usage on CPU0 (attributed by HTOP to the Kernel) which only increases through the day. At the end of the day it starts to imped audio playback (cracks) and makes the system a bit sluggish.

→ Workaround: a reboot makes usage on CPU0 returns at an acceptable level.

Have you seen this high CPU usage on other configurations too ?
Any idea to check what is actually using the CPU so much in the Kernel ?

[Mario_Limonciello]

USB4 is in theory compatible with Thunderbolt-3 and Thunderbolt-4 is backward compatible with Thunderbolt-3.

You’ve got some of this wrong. The USB4 spec has optional support for Thunderbolt 3, it’s up to the silicon and platform designers to decide whether to include it. Framework 13 AMD does include support for Thunderbolt 3 over USB4.

Thunderbolt 4 is an optional certification for a USB4 implementation. It’s up to platform designers whether to certify and brand it this way.

The not so good

Can you please try kernel 6.9-rc5? There is a patch series that resets the USB4 topology at startup that I suspect will help.

Have you seen this high CPU usage on other configurations too ?
Any idea to check what is actually using the CPU so much in the Kernel ?

There are some other threads on this. Look for issues about GPE10 and high interrupts. You should report to Framework support details about it so they can dig into it.

[Nicolas_Masse]

Thanks a lot for the clarification ! I just compiled and booted the 6.9-rc5 kernel. I will test it for a couple of days and report results here.

[Mario_Limonciello]

Cool. Those patches have baked for a few months now too so I also requested those patches to come back to the stable kernels eventually. It would just be nice to get the affirmation sooner and help your issue

[dimitris]

@Nicolas_Masse

When connected all day long, I observe non-negligible CPU usage on CPU0 (attributed by HTOP to the Kernel) which only increases through the day. At the end of the day it starts to imped audio playback (cracks) and makes the system a bit sluggish.

Does this happen only after suspend/resume cycles? Also, if you enable display of kernel thread names in htop, do you see a bunch of kworker/0:n{+-}pm threads? Asking because that’s the pattern I and others see here:

[TRACKING] AMD: small group of kworkers keeping CPU 0 busy after suspend/resume cycle(s)

Fedora 39 GNOME Wayland. Updated description/steps to reproduce (same as from my support ticket, disregard references to log/console attachments): Steps to reproduce (all while connected to the dock): Fresh boot. Configure htop to show kernel threads (capital K to toggle), and also include the core/CPU ID in the results (use F2 to go into setup for that). Run htop (with kernel and note the absence of kworker/0:n-pm kernel threads, especially from CPU 0 where presumably this class of i…

[Nicolas_Masse]

I configured KDE to prevent suspend when I’m connected to the dock.
Today, I worked from home, connected to the dock (no suspend during the day), and at the end of the day I had a lot of CPU usage on CPU0:

It looks like the kernel thread you pointed out, are quite hungry on my system too!