Can you run fw_printenv | paste-log and send me the output?
Cheers
Here is the output of fw_printenv: https://paste.osmc.tv/zoyusubaji
Here is the output of grab-logs -A: https://paste.osmc.tv/lesebiwide
I booted into the Vero with the ssd plugged into the usb3 port and a keyboard to the usb2 port (so I could dump the logs).
Not forgotten… Thinking.
1 Like
I was thinking about creating a bootable usb pen drive with either a fresh copy of osmc (ensure if that’s easy to do) or another OS, plugging that into the usb2 port, and connecting a keyboard to the usb3 port.
If the keyboard works in that situation, it would at least rule out it could be an hardware issue (since a keyboard plugged in into the usb3 port doesn’t seem to be working in any pre/post boot situation).
Do you think it would be worth the experiment?
Well the smallest bootable OS would be the OSMC installer which reinstalls OSMC.
You get a 60 second warning before the device is formatted, so you could just unplug the device (completely safe) before the timer counts down. If you see that screen, the USB is functioning fine.
Sam
I put the osmc installer in a usb flash drive. When plugged in into the usb2 port it boots into the “formatting in 60s” screen. When plugged in into the usb3 port I don’t get anything. It just keep waiting until it times out waiting for my SSD as configured.
Okay, so you aren’t testing the pen drive in isolation?
It could only take one problematic USB device to cause this issue, if you get my point.
No no, I did test it in isolation. I tested the boot with only the pendrive in usb3. It just hangs in the osmc logo screen because my setup in fstab waits for the ssd to connect before proceeding.
Got it now.
I’ve bought a couple of USB3 drives.
I’ll see if I can reproduce the issue
1 Like
Any luck with this? In my day-to-day, the usb2 speed limitations aren’t too noticeable, but I’ve recently had to do some more IO-bound work, and it definitely made a big difference.
I’ve bought a couple of USB3 drives.
In the tests, it might help to remember that a simple keyboard in the usb3 port doesn’t work as well as per: Cannot mount usb3 ssd on boot - #9 by queimadus
Hi @sam_nazarko , any update on this? These 2.0 speeds really take a toll on the day to day interactions.
It doesn’t look like it quite lines up unless you happen to have a chip that is maybe partially messed up or with a cold solder joint but had you seen this post and tried the test when it was in its failed state?
It might be related.
The internal Terminus USB 2.0 hub (1a40:0801 Terminus Technology Inc. USB 2.0 Hub) mentioned in that post does not appear in lsusb.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2516:003c Cooler Master Co., Ltd. MASTERKEYS PRO S with intelligent RGB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I re-tested booting the vero with the ssd connected to the usb3 port (and even tried it with another portable usb3 hdd) and got the same behaviour as before. On boot nothing is detected in lsusb, and once I replug the device into the same port, it appears.
I also have the original remote here, but I never paired/connected it to the vero (I control it via HDMI CEC). But happy to do something with it, if it helps with the diagnosis.
(I continue doing these tests via the on-screen terminal, because I have the booting setup configured to await for the ssd - so it’s not as easy to copy-paste text; the cooler master is the keyboard connected to the usb2 port I’m using to interact with the terminal)
I haven’t really tracked this particular issue too close so I’ll wait for @sam_nazarko to advise for next steps when he visits the forum next.
Regarding your pause at boot, have you tried switching from fstab to autofs to at least make your boot process a bit less painful? Because autofs mounts on demand it does not hang the boot process waiting for the drive to show up like you have now.
When connected via usb2 it never fails so I don’t mind having the strict boot sequence. For my current setup I don’t need it to be boot prior to the disk being ready.
But I would, of course, change that temporarily to perform any debug instructions needed.
I even guess that if during boot there was a way to:
- have the disk plugged into usb3
- somehow restart the usb3 interface the same way that replugging the device back into the port forces it to start working
- and continuing the boot from there
would probably be fine for me too. the current issue is that even though I can make a usb3 port kinda work by manually re-plugging it, any restart to the device leaves it in a unusable state.
Some things (but not the OS) make use of that mount, so I wouldn’t want to start normal operations until that disk is mounted.
UPDATE: I tried the software reset approach with an LLM but didn’t manage to make it work. Here are some things that were tried:
- Unbind/rebind xhci-hcd.0.auto — xHCI was fully removed and recreated, the USB2 keyboard disconnected/reconnected normally, but the SSD remained absent.
- Unbind/rebind the USB3 PHY (fe03a080.usb3phy, driver amlogic-new-usb3-v2) — SSD remained absent.
- Full sequence: unbind xHCI → unbind USB3 PHY → bind PHY → bind xHCI — SSD remained absent.
- USB3 root-port power cycle using uhubctl -e -l 2 -p 1: the port genuinely went from off back to power 5gbps Rx.Detect, but the SSD still wasn’t detected.
- USB3 warm port reset using BH_PORT_RESET — request was accepted, but the SSD remained absent.
- Explicit SuperSpeed link-state cycle: SS.Disabled → Rx.Detect — both requests were accepted, but the SSD remained absent.
I am catching up on this
Sam