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

[NerdENerd]

I replaced zImage_dtb in release_20210906 with the file from zImage_dtb_5.14_hub_debug.zip and it works fine. There are no debug messages in Putty and my keyboard works fine. dmesg shows the hub working and my keyboard being recognised.

login as: root
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server
/root# dmesg

...

[ 2.432864] usb 1-1.1: Product: Logitech USB Keyboard
[ 2.432873] usb 1-1.1: Manufacturer: Logitech
[ 2.462097] HID usage: 0x00010006, original interval: 10
[ 2.467429] HID usage: 0x00010006, applied interval: 10
[ 2.472974] input: Logitech Logitech USB Keyboard as /devices/platform/soc/ff b40000.usb/usb1/1-1/1-1.1/1-1.1:1.0/0003:046D:C315.0001/input/input0

...

/root#

[OnCor]

So I was very focused on copying/pasting the log messages in Putty that it never occurred to me to even test whether the new zimage_dtb file would work if I hooked my MiSTer up to the TV and tried to use the controller and other accessories. I took the SD card with the newest release and the debug file and popped it in my machine. At first nothing worked when I turned on the power. However, just to be 100% certain I powered down the DE-10 and then fired it up again. Sure enough I could see the access light blinking on the SATA cable and the controller let me navigate the menu. At this point it seemed like it might be too good to be true. I have a few different SD cards laying around and I wanted to be 100% certain this was the newest Linux release. I grabbed another card, used the SD Installer created for 9/6 to install Linux, copied over all my cores and other files, swapped out the zimage_dtb file, and popped it in the MiSTer. To my dismay, my hub and peripherals weren't recognized. I forgot that I had not created a u-boot.txt file and so I did that. I put the card back in my MiSTer and it still didn't work. I pulled it back out and decided to change the v=loglevel value from the default 4 to the 9 we used for testing. Sure enough I inserted it into the DE-10 and I could see the HDD access light blinking. I tested the D-Pad on the controller and it worked as well. So it appears when the new zimage_dtb file is in place and v=loglevel=9 is set in the u-boot.txt file then the hub and peripherals are recognized. Just to do a sanity check, I changed v=loglevel back to 4 and tried the card. The peripherals no longer worked. I reverted back to 9 and everything worked again. Hopefully whatever was enabled by this combo can be added to the official Linux installation build. I'm sure it will make many folks with bum USB hubs very happy.

[NerdENerd]

Log level 4 also stops my hub working. I booted the card I replaced zImage_dtb with the build paulbnl supplied and the keyboard was working fine with log level 9. I changed the log level to 4 and reboot via the menu and the keyboard still worked but it did not work after a power cycle.

[Merlkir]

Man, thanks for testing this so thoroughly and I hope your fix can be applied to the next general update.

[bazza_12]

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

[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.