search

mvp / uhubctl

uhubctl - USB hub per-port power control
Other
2.23k stars 232 forks source link

Switching only works properly as root #432

Closed Hypfer closed 2 years ago

Hypfer commented 2 years ago

I'm seeing a bit of a weird behavior on an x86 based Host running the latest Debian Bookworm (current testing) with kernel 5.18.0-2-amd64 and libusb 1.0.26. uhubctl was built from commit 06e7240db6150d2f5a753c22bfd4f0b2d658324a My hub is the Amazon Basics HU3641V1.

When executed as root, uhubctl switches the port just fine. When executed as a non-root however, uhubctl reports that it did switch the hub but apparently it doesn't?

log as root:

Current status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0103 power enable connect [0a5c:21ec Broadcom Corp BCM20702A0 001986002E2D]
Sent power off request
New status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0000 off
Current status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0000 off
Sent power on request
New status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
  Port 1: 0101 power connect [0a5c:21ec]

dmesg when switches as root:

[226604.804884] usb 1-4.1: USB disconnect, device number 44
[226609.060036] usb 1-4.1: new full-speed USB device number 45 using xhci_hcd
[226609.177537] usb 1-4.1: New USB device found, idVendor=0a5c, idProduct=21ec, bcdDevice= 1.12
[226609.177620] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[226609.177661] usb 1-4.1: Product: BCM20702A0
[226609.177689] usb 1-4.1: Manufacturer: Broadcom Corp

log as a regular user:

Current status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
Port 1: 0107 power suspend enable connect [0a5c:21ec]
 Sent power off request
New status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
   Port 1: 0000 off
Current status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
   Port 1: 0000 off
 Sent power on request
New status for hub 1-4 [2109:2811 VIA Labs, Inc. USB2.0 Hub, USB 2.10, 4 ports, ppps]
   Port 1: 0101 power connect [0a5c:21ec]

dmesg when switched as a regular user:

[226374.261021] usb 1-4.1: reset full-speed USB device number 44 using xhci_hcd

(repeated if executed multiple times)

In both cases, the command executed was uhubctl -a 2 -p 1 -l 1-4

The recommended udev rule is in place and seems to work as uhubctl could not see the hub running as a regular user before its creation.

cat /etc/udev/rules.d/52-usb.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="2109", MODE="0666"

Previously, I've used uhubctl on a pi3b+ running raspbian 10 and 11 with no issues. As a workaround, I have now set the suid bit on the binary which makes switching work even as a regular user

mvp commented 2 years ago

Not sure what's going on here. Your kernel 5.18 seems very new. Perhaps newer kernels require different permission model, e.g. using capabilities? Do you see any other errors in dmesg when not running as root (and not suid)?

Hypfer commented 2 years ago

Strangely, it's really just the [230304.886220] usb 1-4.1: reset full-speed USB device number 51 using xhci_hci

Running the same command as non-root in quick succession multiple times with a short delay (1-2s) inbetween, I do sometimes get these log messages as well as a working power-cycling.

[230672.132642] usb 1-4.1: Failed to suspend device, error -32
[230672.645665] usb 1-4.1: USB disconnect, device number 62

However if the delay between the two executions of uhubctl is too large, then I just get another reset full-speed USB device. Also, if I do that too often, the USB hub itself seems to lock up occasionally

mvp commented 2 years ago

Do you have ability to use RPi4 image with older kernel on your hardware? My hunch feeling is this has something to do with most recent Linux kernel 5.18 changes.

Hypfer commented 2 years ago

It's not a Pi4 but a regular x86 computer (a Wyse 3040 Thin Client to be precise). I can try an older Kernel nonetheless. Would 5.10 be old enough or even too old?

mvp commented 2 years ago

I think trying 5.10 should be okay. Best approach would be to do a binary search, but that is of course quite difficult if you are not kernel developer. Better yet is to debug this inside the kernel...

mvp commented 2 years ago

I am closing this because I don't think this is is something that uhubctl code can fix. However, if you do find the reason for this discrepancy and if there is a way to solve it (perhaps changing udev rules or kernel parameters?), please let us know to update README accordingly. Thank you @Hypfer!