QubesOS
USB C dongles crash sys-usb (along with the rest of the system)
Qubes OS release
4.2.1
Brief summary
Whenever I plug in a dongle (USB 3.0/2.0) into the USB-C slot on my computer before manually starting sys-usb, or boot into Qubes with a dongle attached before the login screen, the entire OS freezes, and then reboots. This occurs with two different dongles, both with things attached to the dongles and without.
What is odd is that if the dongle is not attached while sys-usb starts up, everything works fine. If the dongle is attached after sys-usb starts up, the dongle behaves perfectly.
Steps to reproduce
- Have USB-C dongle plugged in
- Start sys-usb, either automatically at boot or manually after boot.
- System freezes, and then crashes after a few seconds
Expected behavior
Dongle is recognized, just like it is when it is plugged in after sys-usb startup.
If not that, then sys-usb at least won’t recognize/initialize it at boot.
And if not THAT, then it should only crash sys-usb, not the entire system.
Actual behavior
Crashes entire system.
Because of the reboot behavior, one could accidentally turn on their computer with a dongle attached and infinitely bootloop the computer before they realize something is wrong.
(I didn’t see anything important in logs, although admittedly I’m not sure where to look. )
Can you share a bit more info about your hardware? What CPU, what USB controller (built-in, or some extra PCIe card?), does it apply only to a specific dongle, or anything on USB-C (IOW, have you tried with a different USB-C device)?
Are you using USB keyboard (or have you removed rd.qubes.hide_all_usb from kernel cmdline for any other reason) ? See https://www.qubes-os.org/doc/usb-qubes/#usb-keyboards if this situation applies to you.
As for logs, getting them on such crash is not easy. If you have a serial console port (unlikely in a recent hardware), you can try that. Otherwise you can check if something interesting got saved to /var/lib/systemd/pstore (some kernel crashes are saved via UEFI variables, and extracted to that dir on the next startup).
Thanks for the quick response :)
CPU: AMD Ryzen 7 5700U The USB controller is built-in, but shows up on lspci as “AMD Renoir/Cezanne USB 3.1”. There are two of those controllers.
I am using a USB keyboard; I haven’t changed the kernel cmd line. I have previously verified that the keyboard is connected via the controller that does not handle the dongle (my device only has 1 USB-C port)
The directory you mentioned is empty.
I am able to boot the system with a removable storage device in the USB-C port; the two dongles register in lsusb as Realtek Semiconductor and Genesys Logic Inc. The bus device that they plug into is labeled simply “Linux Foundation 3.0 root hub”
That does sound similar, since it seems to be an issue with the port being occupied
I don't think it's the exact same though, as I am able to use non-dongle things in the port and the device is not a Framework
I think I also had this behavior when unplugging a USB-C monitor (with integrated USB hub) and was able to reproduce it.
System:
- Qubes 4.2.1
- CPU: i7-9850H
- built-in USB Controller
- USB-C monitor: Dell P3421W
-
rd.qubes.hide_all_usbremoved from kernel cmdline
Reproduction:
- Start system with monitor connected
- Login and verify sys-usb is running
- Unplug monitor -> System resets
Some observations:
- the issue occurred only on a Thunderbolt port, not on USB-C/3.2
- I didn't find relevant logs, logs just end when the system resets
- the issue did not occur when connecting the monitor after sys-usb was already running
- the issue did not occur when re-enabling
rd.qubes.hide_all_usb
I didn't test other USB-C devices as the kernel parameter mitigated the issue, but also had crashes using another USB-C monitor.
I've debugged this behavior in my system and found a workaround, see comment#2582246957. I'm hesitant to make a pull request though; I only have a single system to test on and I don't fully understand the difference between the Linux rebinding methods.
