ThinkPad P16 Gen 3 sys-usb failure

Hello,

I just received a brand new Lenovo ThinkPad P16 Gen 3 laptop. As it’s really a
very recent laptop design, it seems that it’s not totally supported by Qubes and
by Linux. I know I will have some problems…

To get a first view on how it’s supported by Linux, I have booted Ubuntu 25.10 and some devices are not working (at least audio output, no webcam) but at a first glance, it works. Kernel is in version 6.17.

I have installed Qubes R4.3.0rc2 with kernel-latest (version 6.15.11). The sys-usb VM does not want to start. The message found in systemctl status qubes-vm@sys-usb.service (as said in the pop-up) is Start failed: Requested operation is not valid: PCI device 0000:80:14.0 is not assignable, see /var/log/libvirt/libxl/libxl-driver.log for details. The file /var/log/libvirt/libxl/libxl-driver.log is empty. If I perform the installation not requesting a sys-usb, it works at a
first glance.

lspci command result:

80:14.0 USB controller: Intel Corporation Device 7f6e (rev 10)

and qvm-pci says:

dom0:80_14.0   PCI_USB: Intel Corporation unknown pci device

By the way, a lot of devices are said to be unknown.

A few questions for you:

  1. Do you have an idea of what is happening? It seems that dom0 succeed in using the USB interface anyway but is not able to transfert the PCI device to sys-usb.
  2. How can I monitor the improvement of P16 Gen 3 support by Linux and Qubes? Do you think it would be enough to see “lspci” displaying no more “Device 7f6e”? I interpret as that behaviour as device is not known and may not be correctly handled.
  3. How can I help?
  4. Next step is to look at the suspend modes…

Thanks,
Bertrand

2 Likes

So, some news about my problem:

  1. It seems that Ubuntu 24.04 at least is working quite well. The shutdown and the suspend do not work, but I can live with that.
  2. https://linux-hardware.org says that the devices on my PC are supported by Linux. The main issue does not come from Linux not supporting my PC…
  3. So this puts me back in the PCI device “is not assignable” error. I have searched on google and I did not really found any interesting info. Even in xen, I did not see any reference to that error, except sometime more than 10 years ago.

So the questions: How I can further investigate? Do you have any advice? Should I open a bug report?

Thanks
Bertrand L.

2 Likes

That’s a nice laptop, hopefully you can get it working.

Have you tried installing 4.2.4 ? It might not fix the issues since rc2 is newer. However I have been following 4.3 from alpha to rc2 and when installed on my older machine that runs 4.2.4 smoothly, 4.3 has USB bugginess

Thinkpad P16 gen3 certified for Fedora.
Issue most likely related to Xen, but did you fully update dom0 and sys-usb template before decision?

Can you try Fedora 41 and 42 livecd for supporting of USB ports on your device?

Yes I tried R4.2.4, it has the same behaviour. I try to get R4.3.0rc2 to work as it’s the future!

Thanks,
Bertrand L.

1 Like

Hello,

I have not seen any place where P16 Gen 3 is said to be certified for Fedora, except on the PSREF. If you have a reference, I would love to see it!
On Fedora 42 live USB, USB ports are working.
This is why I am back at a Qubes or Xen issue.

Thanks,
Bertrand L.

Operating System
Windows 11 Pro — Lenovo recommends Windows 11 Pro for business

Windows 11 Home

**Fedora® Linux®***

Ubuntu Linux®*

Red Hat® Enterprise Linux®**

*Select versions available via preload. 

**Select versions are certified.

Thank you. I have seen that page, and it’s the reason why I brought this laptop.
I would prefer a page from Ubuntu or from Fedora annoucing the support… I don’t see those pages yet.

Thanks,
Bertrand L.

In QubesOS 4.3.0rc2, dom0 is based on fedora 41. That Fedora 42 work fine your device USB ports, means in case Fedora 41 don’t support your hardware out from the box, it likely has patch with such support.

May you check USB ports also with Fedora 41 live cd?

I just installed Fedora 41 and made all the updates. USB looks to run fine but the audio does not work (as with Qubes R4.3.0rc2).
I am very surprised of this result as the Linux kernel is 6.17.4 whereas Ubuntu with kernel version 6.14.0 does work.

All this makes me get back at a PCI problem., so the message Start failed: Requested operation is not valid: PCI device 0000:80:14.0 is not assignable, see /var/log/libvirt/libxl/libxl-driver.log for details when I try to lauch sys-usb.
xl get-assignable-list is empty but it is also empty on a Lenovo ThinkPad T580 where Qubes is working fine.

Another strange behaviour is about the lspci command. When I launch it on Ubuntu or Fedora, the first time it fails with
pcilib: Cannot open /sys/bus/pci/devices/0000:89:02.0/config lspci: Cannot open /sys/bus/pci/devices/0000:89:02.0/vendor: No such file or directory
and if I relaunch it just after the first time, I get the expected reply. The first time I launch it, it’s on this device which that is a PCI bridge to Thunderbolt 5, but every (?) time after that, it’s for another device (0000.b2:00.0), that is not listed is lspci output (when it works) but is present in /sys/bus/pci/devices/ directory.
On contrary, on Qubes R4.3.0rc3 the command seems to work correctly.

Thanks
Bertrand L.

Try to setup hvm’s based on Fedora-42-xfce (copy) for sys-audio or sys-gui and sys-usb.
Set kernel to “(Provided by qube)” for templates and relevant Qube.

P.s.
Sys-gui handle also sound, so you should choose between sys-sound and sys-gui.

For sys-audio, yes it should work. I will try it later.

My main issue is for the sys-usb that does not accept to be launched. The error message is given in the first message. This happen before the qube can provide its kernel.

Thanks for your time,
Bertrand L.

I have been looking for information on “PCI phantom functions”, and I am wondering if they are contributing to this problem.

You mentioned functions 80:14.0 and .5 in the “sys-usb crash” thread.

If the other missing functions are used by the device, for thunderbolt or other things, but without being advertised, then that could or should prevent passthrough, except if Xen/Qubes knows about them.

Maybe a pci-phantom=... option to xen could help, as in this issue.
This is only guesswork. It might (or not) be useful to compare the lspci output for the device when different drivers/OS are being used, and when different usb/thunderbolt devices are plugged. Do different functions appear, depending on how the device is used?

I do not think that any “unknown” descriptions in lspci are causing passthrough failure - these descriptions come from an external database and play no part in the “mechanics” (see man lspci for details). Maybe a future kernel or xen release could “know” about the details of the device, but it should be possible to attach a device which has no driver or lspci database info in Dom0. Maybe a future BIOS/motherboard firmware release could also make phantom devices be correctly visible on the bus.

Anyway, it’s just an idea from someone who really doesn’t know what they are talking about… but who is interested to know what you find.