Minas, some of the things noted below may require your attention. In particular, the usbmon traces don't show the root hub doing what it should, which leads me to wonder whether the Genesys Logic hub attached to port 1 really is getting suspended and resumed properly. 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. > 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. > 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? > - stop the usbmon dump > > The result of this test can be found in: > 0u.mon-odroidc1-plugged-during-boot-disable-autosuspend.out That was the first attachment. > 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. 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: 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. 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/*". 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. > > It's possible to create a udev script that will perform this action > > automatically at startup (does your OS use udev?). Again, the only way > > to see if the Corsair drive will then work is to try it. > I am an Arch Linux ARM user so udev scripts are possible. > > > If this doesn't work, I think the only solution will be a kernel patch. > Personally I'd prefer a kernel patch (maybe with some flag in > device-tree like broken-remote-wakeup) as from my understanding all > Odroid-C1 and Odroid-C2 (both using Amlogic SoCs) boards are affected. > As a reviewer of the Amlogic platform patches I'd rather avoid > recommending some udev rules for every user. I want to nail down the actual reason for the problem before recommending any changes. > > One other thought: It may be that the reason the Corsair drive and > > others don't work when they are plugged in before boot-up is because > > they are too slow to connect to the USB bus. That would cause the > > Genesys Logic hub to go into runtime suspend before the drive is > > detected, and then the hub never resumes because its remote wakeup > > support is faulty. > > > > You can test this guess by plugging the Corsair drive into the Odroid > > before booting, and adding "usbcore.autosuspend=10" to the boot command > > line. This will cause the hub to delay for ten seconds before going > > into runtime suspend, and that might be enough time for the drive to > > connect to the bus and be detected. > usbcore.autosuspend=10 doesn't make any difference for me, the device > is still not detected. > With autosuspend disabled it's quick to detect the device (I haven't > timed it but it's below 2 seconds). In the second usbmon trace, the detection required 2.05 seconds from the time when the GL hub was resumed. This may explain why waking up the hub with "lsusb -vvv" doesn't cause the drive to be detected; the hub may be suspended again before the drive shows up. But it doesn't tell us what happens during boot-up, and unfortunately there's no way to start a usbmon trace at that time. Alan Stern
