I installed Qubes 4.1 on a Framework laptop and I’m really happy with it. The only problem I have is with sys-usb. I keep seeing “device connected/device removed” prompts, almost continuously. The device in question is unnamed. After a while, sys-usb stops working. There is no way to start it up again as qubes complains (unable to reset PCI device).
This issue has been already mentioned elsewhere: Framework Laptop - #22 by nereocystis
Yet, no conclusive fix seems to have been found. In my case sys-usb was based on Fedora from the start.
I’m glad that you are starting this topic.
Mostly USB works on my Framework.
My only major problems with USB is with the camera and my android.
I will add my thoughts.
My sys-usb is based upon Fedora, and is disposable. My attempt at using Debian disposable had “device connected/device removed” prompts. After reinstalling Qubes with Fedora disposable, I no longer get that problem. I’m not sure this is relevant.
And I have used a handful of USB devices without almost no problems:
USB sticks
coffee roaster
headset, with USB adapter
A couple of times, I had trouble with the roaster. Rebooting eventually fixed the problem, but I didn’t have the continuous message problems.
I recently had trouble with one of my USB-A expansion cards. Pulling it out and setting it in again fixed the problem. If you have a USB-C device, you could bypass the expansion card and plug it in directly. Or try a different expansion card.
A couple of times sys-usb did not automatically start up, or didn’t work when it did start. I manually started the Qube, or restarted it, with some success.
The camera does not always stay connected to the chosen Qube. I had similar problems with my Purism Librem 13.
I cannot attach my Android to any Qube other than sys-usb. Again, I had a similar problem with my Librem 13.
Both of these problems are quite annoying. Especially the camera, which might disconnect in the middle of a zoom call.
I assume that the Framework laptops are similar enough so that it isn’t a hardware incompatibility problem.
I am using Qubes 4.1 (R4.1)
xen_version : 4.14.4
Linux 5.10.109-1.fc32.qubes.x86_64
Yeah, my main problem is indeed the unable to reset PCI device error that forces me to reboot. Without it my usb-related problem would be much more bearable, as it would just entail some notification spam and an occasional sys-usb restart.
Just a question: Can you hotplug expansion cards? That is, if for instance you swap a USB-A expansion card for a HDMI port does it work out of the box or are you forced to reboot?
I just verified that I can hot swap USB-A to HDMI to USB-A
Though I had to try a couple of times to get my USB drive noticed.
I checked my log files in dom0, and not see ‘reset PCI’, except in some journal files.
So my understanding is that hotplug is disabled by defaul in Qubes. If the internal usbc ports are actually thunderbolt then it is very unlikely that hotplug will work. For what I understood the only solution seems to be compiling a custom kernel that includes the hotplug kernel module.
Imho it would be much better if the module was present but disabled by default. I understand the security implications of enabling hotplug but everyone has a different security profile, so enabling it should be “easy” and up to the end user
Maybe my definition of hotplug is different.
Using HDMI did not require touching sys-usb, though I have also used this once, today.
Anything which is plugged in to USB ports shows up in sys-usb.
From there I can attach it to other Qubes, with the challenges I mentioned of Android and camera.
I have not had to reboot, with the exception of the camera.
I have not compiled my own kernels for Qubes. While I used to compile kernels for various Debian releases, I’m happy not to do that now, and I haven’t done it for Qubes yet.
I wonder whether problems with the camera is due to there being 2 USB controllers, one on CPU, the other on motherboard, which is mentioned below
Under Tiger Lake, there is definitely a mention of a Thunderbolt USB controller, as well as an xHCI controller
and then the 82801DB/DBM EHCI controller.
Not sure how this matters.
[user@sys-usb ~]$ lspci|grep -i usb
00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10)
00:07.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01)
00:08.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20)
00:09.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01)
00:0a.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 (rev 01)
I have been looking around, but still don’t know much.
Shut down sys-usb, bring up the Qube manager for sys-usb, go to Devices
At the bottom is a button which says:
Configure strict reset for PCI devices
At the bottom, this says:
Note: use this option only if an “unable to reset PCI device” error occurs.
Mine show the first option in blue, 00:0d.0
This page mentions PCI reset issues
Here are my settings.
[kevin@dom0 log]$ qvm-pci|grep -i usb
dom0:00_0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller sys-usb (no-strict-reset=True), sys-usb-non-dvm (no-strict-reset=True)
dom0:00_0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 sys-usb (no-strict-reset=True), sys-usb-non-dvm (no-strict-reset=True)
dom0:00_0d.3 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #1 sys-usb (no-strict-reset=True), sys-usb-non-dvm (no-strict-reset=True)
dom0:00_14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller sys-usb (no-strict-reset=True), sys-usb-non-dvm (no-strict-reset=True)
Nice catch! The strict reset for PCI devices allows me to restart sys-usb without rebooting. Still, the Device: is available \ Device: is removed issue keeps pestering me
Problems with sys-usb are pretty well documented. For what its worth, I have qubes running on a Lenovo x230 and a Dell E6530. I get no problems with the Dell with the only difference between the two being that the Dell is set up to recognise mouse/keyboard from booting up. This is not for everyone, but I don’t have a problem with this security weakness. But the Dell has never has a problem with sys-usb.
Likewise this problem didn’t exist for me on the previous version of qubes which I used for ages.
Another problem I’m just noticing: Keeping sys-usb on puts a lot of stress on my CPU. In particular, temperatures rise easily above 80C during routine usage and fans are always on, whereas they are around 50C for the same operations when sys-usb is shutdown.
I have no idea what processes could be the culprits for this, but if someone could point me out to the right terminal magic I’d be happy to investigate further!
This went away for me by using kernel-latest-qubes-vm for sys-usb.
I use debian-11-minimal templates.
Prior to that switch, there was a constant flood of messages and sys-usb used massive amounts of CPU.
If you want to use Qubes kernel-latest in your AppVM based on debian template then you need to install the kernel-latest-qubes-vm in dom0 and select the kernel-latest in your AppVM Qubes Settings in Advanced tab. This works the same for other AppVMs as well and not only for those based on debian template.
More info:
