How to USB power/control | AUTOSUSPEND disable on qubes sys usb

Fib · November 28, 2023, 2:11pm

Hi everyone.

I’m am in a situation where I need to probably disable usb:

AUTOSUSPEND and/or
power/Control
Either from the dom0 and/or sys-usb (USB vm).

I have a windows android software that requires to be initialized via android “BROM_MODE” or “Mediatek Preloader” when the phone is off using volume combinations while inserting the USB cable for the software to initialize. I have used the same software on a windows10 installed laptop without QubesOS and with worked seamlessly.

At the moment I am trying to use the same software in Windows10-StandAlone-VM on Qubes but I am having issues with usb being automatically disconnected from BROM_MODE, then powering the android phone after the device is being detected by the Android software installed in Windows10-StandAlone-VM but this is not supposed to happen. I have disabled the power control option in the Windows10-StandAlone-VM on Qubes but didn’t solve the problem.

After some troubleshooting, I discovered that this is probably caused by the USB AUTOSUSPEND, AUTOSUSPEND_TIMEOUT_MS, power/control and/or power/level configuration in the /sys/bus/usb/Devices/ directory either in the sys-usb or dom0 vm.

I have I changed my disposable USB to a stand-alone us so as to contain the configurations.

I have tried couple approach that I discovered online such as:

Updating the /etc/default/grub file with coreusb.autosuspend=-1
Creating USB Udev rules to disable power/control by set to auto
Using: powertop, tlp and hub-ctrl
None seem to be working at the moment.

I also noticed that in the /sys/bus/usb/Devices/ the external input device configurations are disposable after removal and they are symnlinked so, I can’t update the power/ configurations for inputted usb device individually because it will be discarded and replaced to default configurations after I remove and input the USB again.

I don’t know maybe it’s the sys-usb or dom0 that is responsible for the AUTOSUSPEND and power/ configurations.

I appreciate all your supports to resolve this issue.

Thanks.

fsflover · December 2, 2023, 11:24pm

Might be related:

github.com/QubesOS/qubes-issues

External USB drives possibly interrupting backup by going to sleep

opened 09:57AM - 30 Sep 22 UTC

AlbertGoma

T: bug C: core P: critical hardware support C: usb proxy needs diagnosis affects-4.1

### Qubes OS release Upgrade from 4.0 to 4.1.1 ### Brief summary When doing… a backup of relatively large VMs on an external USB drive the motor stops spinning at a certain point and the resulting file contains only a sequential portion of the data. It's already mentioned it in my comment in issue #7567 as this might be a cause for I/O errors and the fix could probably solve both issues. ### Steps to reproduce 1. Attach an external USB hard drive (in this particular scenario, a 3.5" SATA hard drive on a USB 3.0 dock) with a valid partition table, enough space and a healthy filesystem (in this case GPT and ext4). 2. Start a non-networked disposable VM and mount the drive's _block_ device **sys-usb:sda** (not the USB device) on it. 4. Start the _Qubes Backup_ tool and select around 40 VMs with a few of them having a storage use over 200GiB each, exceeding 900GiB in total. Have some of those GiB filled from /dev/zero and some others from /dev/urandom, just in case. 6. Uncheck the _Compress backup_ checkbox and click _Next_. 7. Set the disposable VM as the _Target qube_ and choose a _Backup directory_ in the external hard drive's filesystem. 8. Click _Next_ until the backup starts. 9. Wait until the backup is apparently finished and the hard drive motor has stopped spinning. ### Expected behavior The restored VMs' logical volumes' storage byte count is identical to the original one before starting the backup. ### Actual behavior In the _Qubes Backup Restore_ tool an I/O error popped out and half of the VMs showed 0 bytes of _Disk Usage_ in the _Qube Manager_. When doing an [emergency recovery](https://www.qubes-os.org/doc/backup-emergency-restore-v4/) all of those 0-byte VMs had an **Unexpected EOF** error in all of their chunks when decrypting them with _scrypt_. One of the VMs' chunks were readable until the 490'th.