On 30/08/2022 16.47, Oliver Neukum wrote:
> 1) force a reset after a resume and call reset_resume() instead of resume()
> 2) block autosuspend if remote wakeup is required
>
> I suspect you are actually using the second effect. Have you
> tested with "usbcore.autosuspend=-1" on the kernel command line.
After further testing, your suspicion is correct.
TL;DR: the two VL812 hubs don't behave well when suspended.
I'd like to prepare a better patch for that issue. What's the recommended strategy? The current patch works, even if only as a side effect and when there's a wakeup source downstream. It's currently in Greg KH's usb-linus branch, and will land in linux-next at some point. I'm tempted to let it be and undo it later in the better patch. Is that acceptable? Or should I ask Greg KH to pull it?
> The interesting test would be to see whether a keyboard, ethernet
> or mouse can wake your system from suspend. Have you tested WOL?
Right, a bit of background to understand what's going on with that dock.
There are actually three USB hubs in the dock: the two VL812, and a third Genesys Logic USB 2.0 only:
$ lsusb -d 17ef:
Bus 002 Device 005: ID 17ef:3054 Lenovo OneLink+ Giga
Bus 002 Device 004: ID 17ef:1019 Lenovo USB3.0 Hub
Bus 002 Device 002: ID 17ef:1018 Lenovo USB3.0 Hub
Bus 001 Device 011: ID 17ef:3055 Lenovo ThinkPad OneLink Plus Dock Audio
Bus 001 Device 006: ID 17ef:1019 Lenovo USB2.0 Hub
Bus 001 Device 004: ID 17ef:1018 Lenovo USB2.0 Hub
$ lsusb -d 05e3:
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. Hub
$ lsusb -tv | grep -B1 -e 17ef: -e 05e3:
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
ID 17ef:1018 Lenovo
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 5000M
ID 17ef:1019 Lenovo
|__ Port 3: Dev 5, If 1, Class=CDC Data, Driver=cdc_ether, 5000M
ID 17ef:3054 Lenovo
|__ Port 3: Dev 5, If 0, Class=Communications, Driver=cdc_ether, 5000M
ID 17ef:3054 Lenovo
--
|__ Port 6: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
ID 17ef:1018 Lenovo
--
|__ Port 2: Dev 7, If 0, Class=Hub, Driver=hub/2p, 480M
ID 05e3:0608 Genesys Logic, Inc. Hub
--
|__ Port 1: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
ID 17ef:1019 Lenovo
|__ Port 4: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
ID 17ef:3055 Lenovo
|__ Port 4: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
ID 17ef:3055 Lenovo
|__ Port 4: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
ID 17ef:3055 Lenovo
|__ Port 4: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M
ID 17ef:3055 Lenovo
The user-friendly port view (front and back refer to the locations of USB-A ports):
1018 [p1] --> 1019 [p1] --> USB3 back 4
| | [p2] --> USB3 back 3
| | [p3] --> USB3 RTL8153 ethernet
| | [p4] --> USB2 CM6533 audio
|
| [p2] --> GL850S [p1] --> USB2 back 2
| | [p2] --> USB2 back 1 "keyboard/mouse"
|
| [p3] --> USB3 front 1 "power"
| [p4] --> USB3 front 2
I have always kept keyboard and mouse on the USB2 ports connected to the Genesys Logic hub. They work there without any problem.
With WoL enabled in the BIOS, there are only two wakeup sources:
$ grep . /sys/bus/usb/devices/*/power/wakeup | grep enabled
/sys/bus/usb/devices/1-6.2.2/power/wakeup:enabled # keyboard on GL850S
/sys/bus/usb/devices/2-1.1.3/power/wakeup:enabled # net
While suspended I can wake up the laptop with the keyboard and everything works.
Moving the keyboard to one of the VL812 ports moves the wakeup source::
$ grep . /sys/bus/usb/devices/*/power/wakeup | grep enabled
/sys/bus/usb/devices/1-6.1.1/power/wakeup:enabled # keyboard on the :1019 VL812 (USB2)
/sys/bus/usb/devices/2-1.1.3/power/wakeup:enabled # net
Now here's the interesting bit. Without "usbcore.autosuspend=-1" I can still wakeup the laptop from suspend, but after waking up the keyboard is gone:
kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71)
kernel: hub 1-6:1.0: hub_ext_port_status failed (err = -71)
kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71)
kernel: hub 1-6.1:1.0: hub_ext_port_status failed (err = -71)
kernel: usb 1-6.1-port4: cannot disable (err = -71)
kernel: usb 1-6.1-port1: cannot disable (err = -71)
After that the port to which the keyboard is connected is essentially dead. Replugging doesn't help, I need to shutdown the laptop (powered via the dock) and cut all power to the dock to get that port back to operational status.
With "usbcore.autosuspend=-1", everything behaves as it should.
I met the exact same behaviour ("dead" port) with USB 3.0 devices too, although in my experience so far only with bus-powered devices. Sample kernel output:
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: usb 2-1.4: device not accepting address 6, error -62
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: usb 2-1.4: device not accepting address 7, error -62
kernel: usb 2-1-port4: attempt power cycle
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: usb 2-1.4: device not accepting address 8, error -62
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
kernel: usb 2-1.4: device not accepting address 9, error -62
kernel: usb 2-1-port4: unable to enumerate USB device
I'll run some more tests out of curiosity to see how things behave in corner cases.
Thanks!
JF
