Powered USB hub and devices connected to it no longer functioning after update

[paulbnl]

If changing loglevel from 4 to 9 makes it work then that indicates a timing issue. The extra logging probably delays something that is normally too fast for the hub.

Try to turn off hub auto suspend with v=loglevel=4 usbcore.autosuspend=-1 in u-boot.txt.

[OnCor]

If changing loglevel from 4 to 9 makes it work then that indicates a timing issue. The extra logging probably delays something that is normally too fast for the hub.

Try to turn off hub auto suspend with v=loglevel=4 usbcore.autosuspend=-1 in u-boot.txt.

I made the changes you suggested and it worked. That is so awesome! I also replaced your zimage_dtb file with the original one and it still functioned properly. The auto-suspend was totally to blame. I guess it just needs to be documented somewhere to add this line to u-boot.txt if you're having USB issues?

That's interesting... on my setup the u-boot.txt doesn't exist only u-boot.txt_example.

You have to create it yourself by removing the "_example" part of the filename so that it becomes "u-boot.txt". Just make sure you add usbcore.autosuspend=-1 in there as recommended by paulbnl above.

[paulbnl]

Nice! So something has changed with auto suspend in kernel version 5.

I don't know what else is affected by disabling auto suspend or if it is even needed. If it is not needed then Sorgelig could disable it by default.

You can also try to change usbcore.autosuspend=3 or higher to see if longer delay times also fix it. It says here that the default should be 2(seconds): https://www.kernel.org/doc/html/v5.0/dr ... delay-time

[bazza_12]

I just found it interesting cos I don't have any of these issues listed.

[NerdENerd]

usbcore.autosuspend=-1 also fixed my issues.

My main SD card had a u-boot.txt that contained

v=loglevel=4 usbhid.jspoll=1 xpad.cpoll=1

it did not work on release_20210906 but changing it to

v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=1 xpad.cpoll=1

seems to have made the hub work.

[paulbnl]

usbcore.autosuspend=-1 also fixed my issues.

Can you also try if usbcore.autosuspend=3 or 5 also fixes it?

[NerdENerd]

Neither 3 or 5 work.

[Merlkir]

v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=1 xpad.cpoll=1

Made both a gamepad and keyboard work, but the inputs are kinda weird, like randomly sluggish and delayed, or some of them seem to not register entirely.

edit: Turning on fast USB polling via a Script breaks this again, no kb or gp functionality.

[NerdENerd]

I just spent a few hours playing with an 8BitDo wireless adaptor plugged into my hub and a PS5 controller and didn't see any random sluggishness. I actually cracked out a few good scores in some games. Typing on the keyboard also feels perfectly responsive.

This was on release_20210906 with usbcore.autosuspend=-1

If you look at the fast polling script

https://github.com/MiSTer-devel/Scripts ... ling_on.sh

It writes

Code: Select all

open("/media/fat/linux/u-boot.txt","w") as file:
file.write("v=loglevel=4 usbhid.jspoll=1 xpad.cpoll=1\n")

so it is not surprising it stops working as it overwrites the usbcore.autosuspend=-1. You already have fast polling on with the entries usbhid.jspoll=1 xpad.cpoll=1 in u-boot.txt.

[ash2fpga]

v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=1 xpad.cpoll=1

Made both a gamepad and keyboard work, but the inputs are kinda weird, like randomly sluggish and delayed, or some of them seem to not register entirely.

edit: Turning on fast USB polling via a Script breaks this again, no kb or gp functionality.

On a whim, maybe try 500hz (2ms) polling instead of 1000hz (1ms) polling?

Code: Select all

usbhid.jspoll=2 xpad.cpoll=2

1 -> 1000hz (1ms)
2 -> 500hz (2ms)
4 -> 250hz (4ms)
8 -> 125hz (8ms)

Several months back, I tried 500hz (2ms) and I felt like I got more consistent controller response (tested with 8bitdo m30 2.4g / NES / Contra).

[Merlkir]

Just 500 Hz on its own - not working.
Changing v=loglevel=4 to v=loglevel=9 - also not working.
v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=1 xpad.cpoll=1 - works, even my wifi dongle lights up, but the keypresses are inconsistent.
v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=2 xpad.cpoll=2 - same thing, works inconsistently.

[NerdENerd]

Just 500 Hz on its own - not working.
Changing v=loglevel=4 to v=loglevel=9 - also not working.
v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=1 xpad.cpoll=1 - works, even my wifi dongle lights up, but the keypresses are inconsistent.
v=loglevel=4 usbcore.autosuspend=-1 usbhid.jspoll=2 xpad.cpoll=2 - same thing, works inconsistently.

What about if you roll back to release_20210711?
Is the controller still inconsistent?

https://github.com/MiSTer-devel/SD-Inst ... n64_MiSTer

Download release_20210711.rar and run the installer, selecting Update Boot+Files will roll you back and leave the rest of you installation alone. Or you could do a full install to a different SD card.

[Merlkir]

I think I had this issue before, but not quite to this extent.
(it's possible my USB hub is bad, or poorly supported, but it wasn't as bad before the kernel update)

[Bear]

Having this issue with a BlisSTer, even when the BlisSTer is upgraded to latest firmware. I'll try changing the usbcore.autosuspend and see if that does anything.

[kerobaros]

My USB hard drive hasn't been working through my USB hub board for... several updates, not sure how many. Hard drive works fine attached to my laptop.

Read through this thread and tried adding the 'usbcore.autosuspend=-1' flag, rebooted; no luck.

Changed v=loglevel from 4 to 9, rebooted again: hard drive is seen and mounts just fine.

Went back into u-boot.txt, removed the usbcore.autosuspend flag, but left the loglevel at 9: hard drive still works.

What does this mean? I have no idea! But tl;dr: changing 'v=loglevel=4' to 'v=loglevel=9' in /media/fat/linux/u-boot.txt was all I needed to get my USB hard drive working through my USB hub board again.