Hi Alan, sorry for the late reply - I've been very busy with offline things. On Wed, Jul 21, 2021 at 5:58 PM Alan Stern wrote: [...] > On Tue, Jul 20, 2021 at 11:55:05PM +0200, Martin Blumenstingl wrote: > > > That's what it looks like to me too. This means that the hub on the > > > Odroid doesn't support remote wakeup properly. Or else the root hub > > > gets the remote-wakeup message and doesn't handle it properly. Either > > > way it's a pretty nasty bug for a significant piece of hardware. > > as a wild idea: I do have a 24MHz logic analyzer. If there was a way > > for me to force the communication between the hub and dwc2 to use > > "full speed" or or slower I might be able to look at the signals on > > the bus. > > in case you're aware of any possibility to force the communication to > > use a slower speed then please let me know. > > In theory you don't need to worry about this. When a high-speed device such > as the Genesys Logic hub goes into suspend, it reverts to full-speed > signalling (see section 7.1.7.6 of the USB-2 specification). > > As such, you can easily measure the change from a suspend signal to a wakeup > or resume signal, although you can't easily tell which device (the computer > or the hub) caused the change. A suspend signal has the D+ line steady at > high voltage (> 3 V) and the D- line at low voltage (close to 0 V). A > resume signal is the opposite, typically lasting only a few (or a few tens) > of microseconds. Great, thanks for this explanation. I'll put this on my TODO list then > > I misread your comment at first and used slightly different steps: > > - boot without usbcore.autosuspend=-1 > > - plug in my Corsair Voyager USB 3.0 flash drive > > - start the usbmon dump > > - echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend > > - (the flash drive is detected automatically) > > - stop the usbmon dump > > > > The result of this test can be found in: > > 0u.mon-odroidc1-plugged-after-boot-disable-autosuspend.out > > This was the second attachment to your email. I double-checked: it seems that I messed up the order of the attachments but not the filenames here > > After that I did the test as I believe you're expecting it to be done: > > - plug in my Corsair Voyager USB 3.0 flash drive > > - boot without usbcore.autosuspend=-1 > > - start the usbmon dump > > - echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend > > - (the flash drive is detected automatically) > > This is weird. Didn't you say earlier that doing the same thing, except for > using "lsusb -vvv" to wake up the GL hub rather than this sysfs write, would > not lead to the Corsair drive being detected? I just verified this again - plug in my Corsair Voyager USB 3.0 flash drive - boot without usbcore.autosuspend=-1 - (device is not detected) - lsusb -vvv - (nothing happens, device is not detected) - wait at least 5 seconds - start the usbmon dump - echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend - (the flash drive is detected automatically) - stop the usbmon dump So it seems that telling the hub not to auto-suspend seems to work around it enough? I attached test-1_hub-autosuspend-1.out to document this result [...] > > In both tests I observe the following in the kernel log: > > usb 1-1: reset high-speed USB device number 2 using dwc2 > > I assume that this brings the hub into a well-defined state where > > remote wakeup may not be relevant > > I saw such a reset only in the first usbmon trace, not the second. It looks > like the reset was performed because of a communication error (the -71 > status code near the beginning of the trace), but it's not at all clear why > the error occurred. you are right, it's only happening for the first usbmon trace > In fact, there were a few strange things in the traces. Let's look at the > start of the first one. The trace starts by showing the root hub > being resumed, which involves asking for the port status: > > c57f1680 41352445 S Ci:1:001:0 s a3 00 0000 0001 0004 4 < > c57f1680 41352762 C Ci:1:001:0 0 4 = 03050000 > > The status for port 1 shows that the port isn't suspended and hasn't > undergone a wakeup transition. It's simply active, as though it had never > been suspended in the first place. > > (For those unaccustomed to reading these traces, the 03050000 status value > above means the following: The two bits in the "3" are "Port connected" and > "Port enabled", and the two bits in the "5" are "Port power on" and "Port is > high-speed". If the port were still suspended, the 04000000 bit would be > set. Notably missing is the bit which would indicate "Port suspend status > change", which is in the 00000400 position and is supposed to be set > whenever the port is resumed because of a wakeup request from the attached > device.) > > c5753280 41352977 S Ii:1:001:1 -115:2048 4 < > > The shows the root hub's interrupt URB starting up, the last part of a > normal resume. > > So was the GL hub actually suspended? It's hard to tell exactly what the > hardware's doing, but you can get a trace that will help. Do the following: at this point I'd like to point out again that it's amazing to have someone with your knowledge about the whole USB subsystem help out on this > Boot with no device plugged in and with "usbcore.autosuspend=-1" on the > command line. Then start a usbmon trace. > > Next, do > > echo 2 >/sys/bus/usb/devices/1-1/power/autosuspend > > and wait a few seconds for the GL hub to be suspended. To make sure it has, > do "grep . /sys/bus/usb/devices/1-1/power/*" and include the output in your > reply. # grep . /sys/bus/usb/devices/1-1/power/* /sys/bus/usb/devices/1-1/power/active_duration:104940 /sys/bus/usb/devices/1-1/power/autosuspend:2 /sys/bus/usb/devices/1-1/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/1-1/power/connected_duration:116500 /sys/bus/usb/devices/1-1/power/control:auto /sys/bus/usb/devices/1-1/power/level:auto /sys/bus/usb/devices/1-1/power/runtime_active_time:104511 /sys/bus/usb/devices/1-1/power/runtime_status:suspended /sys/bus/usb/devices/1-1/power/runtime_suspended_time:11562 /sys/bus/usb/devices/1-1/power/wakeup:disabled (I ran this command twice by accident, but I guess this makes no difference. this is the output of the second run) > Then do > > echo 2 >/sys/bus/usb/devices/usb1/power/autosuspend > > and wait a few seconds for the root hub to be suspended. Again, to make > sure it has, do "grep . /sys/bus/usb/devices/usb1/power/*". # grep . /sys/bus/usb/devices/usb1/power/* /sys/bus/usb/devices/usb1/power/active_duration:130880 /sys/bus/usb/devices/usb1/power/autosuspend:2 /sys/bus/usb/devices/usb1/power/autosuspend_delay_ms:2000 /sys/bus/usb/devices/usb1/power/connected_duration:140000 /sys/bus/usb/devices/usb1/power/control:auto /sys/bus/usb/devices/usb1/power/level:auto /sys/bus/usb/devices/usb1/power/runtime_active_time:130872 /sys/bus/usb/devices/usb1/power/runtime_status:suspended /sys/bus/usb/devices/usb1/power/runtime_suspended_time:9120 /sys/bus/usb/devices/usb1/power/wakeup:disabled > Once that has settled down, wake up the root hub by doing > > echo -1 >/sys/bus/usb/devices/usb1/power/autosuspend > > and a few seconds later, wake up the GL hub by doing > > echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend > > All these suspends and resumes should show up in the usbmon trace. I'd like > to see what it really says; my guess is that it won't show quite what it > should. I attached test-2_autosuspend-steps-without-device-plugged-in.out which contains the usbmon dump for these steps At no point I had a USB device plugged in # grep -o 'usbcore.autosuspend=-1' /proc/cmdline usbcore.autosuspend=-1 Best regards, Martin