I am using QubesOS 4.2.4 on @novacustom V56. This has been an issue that I experienced for a long time, but today I got really annoyed that I finally report it here.
I plug in a USB drive (simple stick) to my USB port (the usual usb type-a or type-c, in both cases this annoyance is present). I click on the USB icon on the xfce4 tray, find my USB drive, and attach it to one of my regular debian/whonix qubes. In the qube, I fill one of the partitions in the USB stick with inputs from /dev/random:
This goes on. The real problem is, while this process continues in the qube, my whole mouse touchpad input experiences stutters and delays. To the degree that I get “ghost clicks” and mouse doesn’t move for one or two seconds at irregular intervals.
Anyone else having this annoying behavior with USB attach mechanism in QubesOS? Any solutions?
@marmarek Hi Marek, do you have any ideas for the issue of this Qubes-certified device? Might it be firmware related or is it rather Qubes? In the first case, I think we have to ask our firmware developers team?
Does your touchpad is usb connected?
If it’s connected by usb then it’s one usb controler with external connector?
How many vcpu your sys-usb have?
How much memory your sys-usb have?
Does sys-usb is forced to use swap?
How many vcpu your dom0 have?
How much memory your dom0 have?
No. It is the regular touchpad that comes with novacustom V56.
2
800 MB, and it is excluded from memory balancing. So, the sys-usb uses 800 MB memory, flat.
I didn’t modify any swap settings. I am simply using debian-12-minimal template (with trixie packages installed. I did a apt full-upgrade on the debian-12-minimal template – but the problem I reported above was also present with debian 12 packages version of the minimal template).
Interesting, I can reproduce this issue.
I see dom0 reporting:
i2c_designware i2c_designware.0: controller timed out
which looks related.
Interestingly, USB mouse seems to be unaffected, which is counter-intuitive since sys-usb handles the data copy in parallel.
There isn’t even much load in either of VMs (sys-usb, the one with dd or even dom0) - below 20% CPU usage in all of them.
Running dd in sys-usb directly has the same effect.
According to /proc/interrupts in dom0 (at least here) i2c_designware.0 uses IRQ 27, and is handled by CPU0 and CPU7. After applying CPU pinning to keep sys-usb out of those cores (and also pin dom0 statically), the issue is gone. But this shouldn’t be necessary…