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

[OnCor]

Hi all. I have a powered USB hub that connects to the DE-10 nano's micro USB port. Attached to that hub are my controllers and a 2.5" HDD. Prior to the most recent "Linux and Main" updates on 8/25 everything worked as expected. The USB hub was recognized on startup and the peripherals functioned properly. Now I cannot seem to get MiSTer to recognize anything plugged into it. I'm assuming that the DE-10 nano is not recognizing the hub itself either. I have an old OTG hub that I plugged in and it still seems to work. I was able to navigate around using my gamepad connected to it. However, I need a powered hub for the HDD which is connected through a USB to SATA cable and doesn't have its own power source. Is there anything I can do on my end to get the hub working?

[Drexl]

I'm having the same problem, although it's not a powered hub. It seems to recognize the hub, since I can log into it via SSH and run lsusb to see it. But neither the keyboard nor the gamepad will work.

[obot]

This may be an issue with some drivers now being loadable modules. Would you try 'lsmod' at the Linux command line (through ssh or console) and see if any modules are being loaded?

[OnCor]

I just reverted back to the previous version of Linux using the SD Card Installer so that I could continue using my MiSTer until this issue is resolved. Plus I'm not that familiar with the SSH process.

@Drexl is this something you can check?

[akeley]

I use an external OTG hub. Since the update my Dualshock's analogue stick stopped working (does still work on my PC). Not sure if this is connected to this issue but it seems likely. Other devices - wireless mouse/KB and wifi dongle work ok via this hub.

How exactly do you revert to the previous version of Linux? I wouldn't mind doing it if it's relatively simple.

[Drexl]

This may be an issue with some drivers now being loadable modules. Would you try 'lsmod' at the Linux command line (through ssh or console) and see if any modules are being loaded?

The only module I see being loaded is dwc2.

[OnCor]

It seems as though there have been some other folks having issues with their USB devices as well after the most recent Linux updates. Here is a different thread about it: viewtopic.php?f=30&t=3175

I imagine lots of users have USB hubs connected to their MiSTer units, but if all of them were impacted I'm sure there would be a lot more feedback coming in. I wonder what could have changed that would only impact certain units?

@akeley you can manually install an older version of the Linux OS using the "Manual Installation Method" in the Setup Guide section of the Wiki. Here is a link to that page:

https://github.com/MiSTer-devel/Main_Mi ... etup-Guide

[OnCor]

I made an interesting discovery this morning. I have two DE-10 Nano devices. One was purchased years ago and the other I got within the last few months. The new Linux updates have impacted the USB hub on the newer unit, but apparently the older one still works just fine. I read a different topic last night (viewtopic.php?f=30&t=3084&p=31342&hilit=usb+hub#p31342) that mentioned there were changes to the micro USB OTG port on the DE-10 between older units and the newer ones. I suspect this might be to blame for the fact that my original device can still see the hub and devices connected to it whereas the newer one can't.

[OnCor]

I noticed there was a new Linux update this morning that mentioned "Ported USB host driver from socfpga-4.19 as more compatible and stable" which I was hoping might fix the issue with my hub. However, when I updated my SD card and tried it in the newer MiSTer the hub and peripherals were still not recognized. The card did work in my older unit though as expected.

[Fallon]

I updated this morning with update.sh. My bluetooth keyboard which is plugged into a usb hub now functions on boot, so fingers crossed the problem is resolved.

[OnCor]

Even after today's Linux updates most of my USB hubs don't work. I have a bunch of identical 7 port USB 2.0 hubs that I'm going to be using in custom cases. They all were tested and confirmed to work before the big changes that were made on 8/25. Now I only have one that appears to be recognized. I bought the working one off eBay to use in designing the cases and then ordered a bunch more off AliExpress when I knew that they would be well suited for my project. They have the same exterior enclosure and the PCBs appear to be the same as well. The only differences are a) that the working unit has a blue power LED and the others have a red one and b) the working hub has a couple of ICs labeled as "HS8836A" whereas the non-working hubs have chips labeled as "MW7211A". Looks like there might be some other differences with smaller components like capacitors and resistors. I'm not that savvy with electronics, so I'm not sure what this ultimately means. A little Google searching seems to indicate that perhaps the hubs with the "MW7211A" chips might actually be USB 1.1 and not 2.0 as they were advertised to be.

[Merlkir]

Yep, can confirm. Mine doesn't work on yesterday's update.

[NerdENerd]

Latest update does not fix my issues with some of my USB hubs.

[paulbnl]

It would be helpful if someone can provide dmesg logs from the old release when the USB hub was working and the new release where it is not working.

Preferably with "v=loglevel=9" in linux/u-boot.txt for debug messages.

Run "dmesg > /media/fat/dmesg.txt" from the console on MiSTer or through the Serial connection: https://github.com/MiSTer-devel/Main_Mi ... connection

[Shuffle7]

My 8 bit do controller no longer works . I’ve tried remapping buttons but nothing registers .. can anybody be help . Linux updated with update all .

[OnCor]

It would be helpful if someone can provide dmesg logs from the old release when the USB hub was working and the new release where it is not working.

Preferably with "v=loglevel=9" in linux/u-boot.txt for debug messages.

Run "dmesg > /media/fat/dmesg.txt" from the console on MiSTer or through the Serial connection: https://github.com/MiSTer-devel/Main_Mi ... connection

I will see if I can do this tonight after work. I've never accessed the console through the serial connection, but I will download Putty and try to follow the steps in the Wiki.

[OnCor]

I attempted to dump the dmesg log through the console using Putty, but ended up with the error in the attached screenshot. Any idea what I might be doing wrong? After getting the error the first time I tried creating an empty file called dmesg.txt hoping that the system would just add details to that. Nothing happened. I tried running the command without the quotes and nothing happened either. Please forgive my ignorance here. I'm definitely a noob with Linux.

Console Error.jpg (9.77 KiB) Viewed 9332 times

[ash2fpga]

Try the command without the double quotes.

[OnCor]

Try the command without the double quotes.

I did actually try it without quotes and it appeared like nothing happened. However, I was looking in the wrong spot for the output file. My bad!

I attached a zip with both files, one with an older version of Linux where the hub is working and one from the newest build where it no longer works. Hopefully this will help diagnose the issue.

[NerdENerd]

I have attached two dmesg output files.

[NerdENerd]

I set log level to 9 and did it again.

[paulbnl]

Thanks for the logs. Looks like dmesg didn't keep all the messages because it is incomplete. There is also not much information about what is happening except that the hub is constantly being disconnected .

I have compiled new kernels for 4.19 and 5.14 with some extra USB hub debug messages. Extract and rename to zImage_dtb and overwrite the old file.

zImage_dtb_5.14_hub_debug.zip

(5.99 MiB) Downloaded 181 times

zImage_dtb_4.19_hub_debug.zip

(7.15 MiB) Downloaded 181 times

If you set v=loglevel=9 in linux/u-boot.txt then the kernel messages should appear in the Putty window. Click the Putty icon on the top left of the terminal window and click "Copy All to Clipboard" and then paste that into a file. That way should give the complete kernel messages.

[OnCor]

I replaced the corresponding zImage_dtb files on both SD cards and captured all the messages in the Putty terminal. I assumed that 4.19 was the older Linux version and 5.14 was the newer one. I also dumped the dmesg.txt files again. I had not set the log level to 9 on the newer u-boot.txt file when I did it the first time. Hopefully the zip file has everything now needed for debugging.

Debug.zip

(30.47 KiB) Downloaded 216 times

[paulbnl]

Thanks. Strange, it looks like the hub is working correctly on the new kernel. I don't see any disconnection messages.

NewLinux.txt shows a Sabrent mass storage device but the dmesg.txt files (Old and New) show no USB devices connected to the hub.

Did you disconnect the devices from the USB hub? Can you access the HDD if it's the only device connected to the hub?

Maybe the issue only happens when you connect a controller.

[OnCor]

Thanks. Strange, it looks like the hub is working correctly on the new kernel. I don't see any disconnection messages.

NewLinux.txt shows a Sabrent mass storage device but the dmesg.txt files (Old and New) show no USB devices connected to the hub.

Did you disconnect the devices from the USB hub? Can you access the HDD if it's the only device connected to the hub?

Maybe the issue only happens when you connect a controller.

My Sabrent SATA to USB cable which connects my HDD to MiSTer was the only thing connected to the hub at the time I pulled those logs. It stayed attached through the entire process. There's a little light that blinks when the drive is being accessed shortly after powering on MiSTer. When I had the DE10 connected to my PC that light did not blink. It stayed solid. Even after I disconnected the device from my computer it took a couple of power on/off cycles before the hub responded and the light on the Sabrent blinked again. I tried to see if I could find my HDD in Midnight Commander when I had Putty running, but it didn't show up in any of the USB devices.

BTW I'm not sure if you noticed in my posts above that I have two hubs that are identical in appearance, but they have different chips on them. One of those hubs works just fine with the new updates. The other one does not. After doing some research it seems that the one which doesn't work may only be running at USB 1.1 speeds. I'm not sure if that has anything to do with the issues I'm experiencing. Perhaps the Linux updates don't actually support the older legacy USB standards?

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