HCL - Lenovo Thinkpad P14s Gen 1 (AMD)

Qubes 4.1 (R4.1)

Fresh install with all default options (Fedora 34, Debian 11, Whonix 16)

Installation and first boot:

  • The installation had a "PCI 002… " error upon completion of install but booted to login screen
  • Network Manager service had to be manually added to NetVM to enable Wireless
  • Manually remove PCI002 (Realtek Ethernet Controller) to remove error
  • Reboot required after above to enable wireless configuration/detection

Confirm working:

- Volume control and mute (F1/F2/F3) with OSD
- FN-lock/FN-lock indicator (FNLOCK/ESC)
- Mic mute/unmute (F4)
- Screen brightness (F5/F6)
- Wifi on/off (F8)
- Capslock/Capslock indicator
- Touchpad (tap/click/scroll)
- Trackpoint and buttons
- Power control (Power button)
- Temperature/fanspeed sensors
- Ethernet (RJ45 , plugged in/out indicated)
- MicroSD reader (detected/readable/writable)
- Integrated speaker (Sound output)
- Keyboard (Tested US keyboard layout)
- Logitech USB Unifying receiver (for Logitech Mouse + Keyboard)

Not tested yet:

- Bluetooth
  • DisplayPort out

Not Working:

- Hibernation (Blank screen)
- Suspend-to-RAM (Close lid,opens to blank screen. Need to hard reboot)

Performance observations:

Boot time is extremely slow: 
    Total startup time is 2mins 50s !!! 
    for comparison on same laptop (total startup, fresh install), 
              Arch/KDE ~ 25s
              Ubuntu/GNOME ~ 30s
              Fedora 34/GNOME ~ 32s 

HCL Output

brand: |
model: |
bios: |
R1BET67W(1.36 )
cpu: |
AMD Ryzen 7 PRO 4750U with Radeon Graphics
cpu-short: |
chipset: |
Advanced Micro Devices, Inc. [AMD] Renoir Root Complex [1022:1630]
chipset-short: |
gpu: |
Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev d1) (prog-if 00 [VGA controller])
gpu-short: |
network: |
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
Intel Corporation Wi-Fi 6 AX200 (rev 1a)
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
scsi: |

usb: |

  • works:
    qubes: |
    xen: |
    kernel: |
    remark: |
    credit: |
    link: |
1 Like

It’s not expected to work (yet):


Thank you @kellyling for your R4.1 HCL report, which is online now.

1 Like

Notes with thanks @fsflover and @Sven

Further update to the above,
Tested the system on kernel 5.15.14-1.fc32.qubes…86_64 (kernel-latest).
Hardware compatibility stands, no new issues.

Performance update to the above,
I should clarify that ‘some’ of the slow boot performance might be attributed to the disk being fully encrypted. For those who want to gain a few more seconds during boot , you can try disabling plymouth from the grub config (GRUB_CMDLINE_LINUX=“rd.plymouth=0 plymouth.enable=0”) on dom0 . Real-world hand timing indicated a gain of ~10secs (Graphical target improved from ~49s to now ~37s). Might gain more by going the minimal template route - haven’t the time to test it out yet.

Overall, R41 (with defaults and no workarounds) has been working good on this laptop as a daily driver for the past 3 days of 8-hour shift work/zoom meetings/heavy worksheet crunching + a few hours of Steam gaming sessions.


A post was split to a new topic: Motion of Windows Have Time Lags in Between Moving Them (Thinkpad L15 Gen1 Ryzen Pro 7)

Just out of curiosity, @kellyling, what does your journalctl say when resuming from S3 sleep. I know you get a black screen, but does it say anything about ring gfx timeout?

I have encountered bugs in amdgpu when running through Xen, causing Xorg to coredump. That’s why I’m asking…

Also, how on earth did you manage to get a Steam session in with integrated graphics? That’s incredible! :dizzy_face: I can barely get 10fps with a 4800U with RX Vega 8…

@alzer89 , I don’t see any ring gfx timeout entries in my journalctl. In saying that, I’ve not seen much amdgpu errors lately.

As for Steam, I guess it depends on the games you’re planning to run. I tested a few ‘older’ titles and they ran pretty decent on low/mid settings. I did set vram settings to 2048M in BIOS, and also used a custom Debian minimal VM .

So, if you S3 sleep (suspend to RAM), does everything work as expected?

Like, it doesn’t implode on resume? No black screen? No crashes?

The context for why I’m asking this: