Compatibility report (TLDR: good) between the Dell U4025QW

Framework Laptop 13 Linux
1

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 ?

1 Like
2

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.

1 Like
3

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. :+1:

4

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 :slight_smile:

5

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:

6

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:

Screenshot_20240424_165113
Screenshot_20240424_1651131206×486 138 KB

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

7

After 12 days of testing, I can say that kernel 6.9-rc5 greatly improved the reliability of the thunderbolt connection between the screen and the Framework Laptop 13 AMD. Most of the time when I connect the laptop to the screen, everything works (display stream + USB).

I had just a couple of times (less than 5 over those 12 days) when the display would not show up.

However, I still have to investigate the high CPU usage on CPU0 after several hours connected to the screen.

8

After I collected some logs again for an upstream-ish bug report, our cases actually appear identical. Suspend/resume not required.

9

I recently updated my system to kernel 6.11.0 and I can tell that:

  • I can now boot, use and shutdown my laptop with the screen connected without experiencing any kernel panic.
  • The high CPU usage on CPU#0 by kernel threads seems gone too.
  • The connection to the screen now works reliably.

I will try to investigate soon if daisychaining improved with kernel 6.11.

10

That’s good news! I assume this is without the disable GPE 10 interrupt workaround?

11

Your assumption is correct!

root@fedora:~ $ cat /sys/firmware/acpi/interrupts/gpe10 
  269235  EN     enabled      unmasked
1 Like