Hi Alan, On Mon, Jul 19, 2021 at 4:53 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Sun, Jul 18, 2021 at 11:24:55PM +0200, Martin Blumenstingl wrote: > > Hi Alan, > > > > sorry for being a bit slow to respond this time. > > > > On Thu, Jul 15, 2021 at 3:44 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > [...] > > > Martin, here's another test you can try, on both the Odroid and PC > > > systems. Boot with usb.autosuspend=-1 on the command line to disable > > Please note that in my tests below I used usbcore.autosuspend=-1 (so > > s/usb./usbcore./) > > I am assuming that usb.autosuspend is a typo because it doesn't seem > > to make a difference for me. > > Yes, it was a typo. Sorry. no need to apologize at all. I just wanted to make it clear what I tested in case someone else reads this and wants to reproduce the result. [...] > > From what I can tell the outputs related to device 005 (on my PC) as > > well as 002 (on my Odroid-C1) are identical up to the point where > > Odroid-C1 is then just silent. > > 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. I am doing this investigation as part of my personal time and I don't have access to high dollar equipment. Anand, in case you have access to better equipment than me (even if not immediately) then it would be great if you could let us know. [...] > These results suggest that the best approach will be to prevent the hub > from going into runtime suspend. You can do this manually by: > > echo -1 >/sys/bus/usb/devices/1-1/power/autosuspend > > This will cause the hub to be resumed even if it was already suspended, > so you don't need the kernel boot-line parameter. However, I'm not > sure whether the hub will then correctly detect the Corsair drive if it > was plugged in before boot-up -- I suspect it won't. Can you try this > out, and start a usbmon trace before doing the "echo" command? 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 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) - stop the usbmon dump The result of this test can be found in: 0u.mon-odroidc1-plugged-during-boot-disable-autosuspend.out 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 > 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. > 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). As always: many thanks for the time you're dedicating to this issue and for all the suggestions you're making! Best regards, Martin
Attachment:
0u.mon-odroidc1-plugged-during-boot-disable-autosuspend.out
Description: Binary data
Attachment:
0u.mon-odroidc1-plugged-after-boot-disable-autosuspend.out
Description: Binary data
