AMD Thinkpad L14 Gen 3 Ryzen 7 PRO 5875U with Qubes 4.2.0

That took a long time to put together, but I know my system better because of it. Better to iron out technical issues now instead of when you’re presenting to an audience.

It seems the only big issues are network devices going down on suspend and video playback. I’m planning on working on network devices next, but smooth video playback was an issue I was unable to fix on my last computer; I would appreciate advice on how to fix that.


Thank you for information!

About playback stopping in a second after start: it is almost always related to sound not being able to be passed to audio qube (dom0 by default). The vchan/sound buffer gets full and playback instantly stops.
Try the video file without audio track (e.g. remove it completely with ffmpeg).

1 Like

That’s awesome information!

I don’t have that problem with mpv. mpv works fairly smoothly unless I seek or pause, which triggers:

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

Disabling audio using --aid=no removes this error message, but I still have the problem that the video will freeze for several seconds.

However, YouTube will never play for more than a split second unless I mute it, then it seems to work fine, including seek and pause.

Using i3 window manager and xrandr --output HDMI-1 --above eDP-1 --auto causes each kind of mouse click to fail in AppVMs, still works fine in dom0 and works fine after you remove the screen and run xrandr --auto.

Edited because after increasing VRAM, the mouse click issue with the second monitor went away.

On resume from suspend, sys-net would show a page allocation failure and CPU Tainted: G

dmesg prior to fix

[ 1067.807736] mt7921e 0000:00:07.0: ASIC revision: 79220010
[ 1067.892557] mt7921e 0000:00:07.0: HW/SW Version: 0x8a108a10, Build Time: 20231120183400a

[ 1067.919520] mt7921e 0000:00:07.0: WM Firmware Version: ____000000, Build Time: 20231120183441
[ 1067.978287] kworker/0:1: page allocation failure: order:5, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
[ 1067.978318] CPU: 0 PID: 1910 Comm: kworker/0:1 Tainted: G        W          6.1.62-1.qubes.fc37.x86_64 #1
[ 1067.978328] Hardware name: Xen HVM domU, BIOS 4.17.2 01/03/2024
[ 1067.978336] Workqueue: events mt7921_init_work [mt7921_common]
[ 1067.978350] Call Trace:
[ 1067.978356]  <TASK>


sudo rmmod mt7921e
sudo modprobe mt7921e

Fixes the problem.

As suggested by Suspend/resume troubleshooting, I did

echo "mt7921e" >> /rw/config/suspend-module-blacklist

Then I suspended and resumed, but WiFi doesn’t work. dmesg has the same error as before, followed by:

mt7921e 0000:00:07.0: register device failed

I tried,

sudo rmmod mt7921e

but this resulted in sys-net crashing. I repeated this with the same effect.

I tried suspend again, and this time ran:

sudo modprobe mt7921e
sudo rmmod mt7921e
sudo modprobe mt7921e

And it worked. I repeated that and it worked again.

Ultimately, I ended up removing mt7921e in /rw/config/suspend-module-blacklist and instead implementing this behavior manually:

Automated fix


binds+= ( '/etc/pm/sleep.d' )



case "${1}" in
		sudo rmmod mt7921e
		sudo modprobe mt7921e

This ran into a lot of issues, so I fell back to just manually running sudo rmmod mt7921e && sleep 0.5 && sudo modprobe mt7921e


WiFi reconnects automatically with some additional configuration. The only major item left is video+audio playback. Do you know how to fix audio playback?

What else do I need to do to get this on the community-recommended list?

  1. This list is kind of outdated and does not reflect the current situation. You can see it only consist of outdated laptops and certified ones.
  2. Its rules are to strict, even laptops that require NO additional steps like you have with wifi, failed to get into it.

If/when the new extended compare/recommended list is created, this laptop can definitely hope to get there.

1 Like

For some reason,

qvm-features dom0 gui-videoram-min $(( (1920 * 3840) * 2160 / 1024 ))

Did not persist between reboots, so I added it to ~/.profile

Edit: Did not work, so I changed it to:

qvm-features dom0 gui-videoram-min $(( (1920 * 3840) * 2160 * 4 / 1024 ))

If it is not an expected behavior, you should report it on github issues.

Great that works without problems on 4.2! I’m still on 4.1, I have to see when I have time to upgrade. Maybe a clean install is better for the HCL/recommended list, but obviously that takes more time, so I’m not sure when I’ll have the time for that.

Checking CPU frequency does not work properly on Qubes for some methods.
Try xenpm start 1|grep "Avg freq"while doing something CPU intensive.


CPU boost works! Thank you.

1 Like

Thank you for all the info. I noticed: 25 min. zoom call - minus 30% battery. How is the battery time on average use approximately? Qubes is rather battery consuming,

It seems really good compared to my T450s with an old battery. On the L14, the battery seems to last 3-5 hours of use.

1 Like

That’s pretty good. I have seen often in tests that those AMD Ryzen 7 CPUs have better battery performance in general than comparable Intel CPUs (like Ryzen 7 7840HS vs i7-13700H).

I got video playback including YouTube working smoothly by switching to Debian and installing pulseaudio-qubes. HDMI audio no longer works after updating Fedora, but it works on Debian.

I’m still having the same issue as Scumbag: pciback ... not ready ___ms after FLR. This delays the startup of the sys-net by about a minute.

I have installed R4.2 on my L14 and also experienced WiFi not working after suspend, which is also fixed by reloading kernel module in sys-net. I did not have this issue in R4.1 so I found that strange. The only other difference I could think of was that I used the default Fedora template in R4.1, but R4.2 uses Fedora-xfce.
When I switch sys-net from fedora-39-xfce to fedora-39, WiFi works again after suspend without needing to reload kernel modules.
So that would make it a template issue instead of a hardware compatibility issue.


Interesting. fedora-39 no longer works for me, with or without my workaround.

However, switching sys-net to debian-12-xfce fixed the issue.

Edit: It is not totally fixed. It seems to work most of the time, but still requires rebooting sys-net occasionally.


@zaz willing to test AEM trenchboot? I am just about to retire my T480 as a testing machine and wanted to get the L14 for my daily.

A week from now, I will have enough time to risk messing with my computer. However, it seems trenchboot is still not working for AMD. See their Github Milestone.

1 Like

Now we have a second good report for R4.2 on the L14, so I hope it can be on the community recommended list: