Hi! We’re seeing an issue that looks related to what’s reported in these two threads, but with a detail that might be useful for narrowing down the root cause — for us it’s not new to R36.5.x, it’s already present on R36.4.7:
- USB Devices Not Enumerated on Boot After Installing JetPack 6.2.2 On Jetson Orin Nano
- USB 3.0 not recognized after upgrading Jetson platform from R36.4.3 to R36.5.0
Setup: Jetson Orin Nano Super, external USB peripheral (Android-based device, appears as 05c6:9091), connected either directly or through a USB hub (tested with both a Terminus 1a40:0101 ganged-power hub and a Huasheng 214b:7250 per-port-switching hub).
Symptom: if the peripheral is plugged in before boot, it never enumerates — no lsusb entry, no kernel log entry at all for it. journalctl -k -b 0 shows the USB-C controller (fusb301) reporting a detach state, i.e. it doesn’t even see something electrically connected, let alone attempt enumeration.
Versions tested:
- R36.4.7 (our production baseline) — fails at cold boot with the device pre-connected. This is already our starting point, not something we introduced by upgrading.
- R36.5.2 (upgraded one unit specifically to test whether this fixed it) — identical behavior, no better, no worse.
Workaround confirmed on both versions: physically unplugging and reconnecting the USB cable after the system has finished booting makes the device enumerate correctly every time. We’ve also confirmed that once a device has been seen at least once, toggling /sys/bus/usb/devices//authorized (0 then 1) forces a clean re-enumeration without touching the cable — but we haven’t yet confirmed whether this trick also recovers the “never seen since boot” case (the fusb301 detach state), or whether that requires an actual electrical disconnect (e.g. via uhubctl).
Given we reproduce this already on R36.4.7, we’re wondering whether this is the same root cause as the R36.4.3→R36.5.0 regression reported in the threads above, or a separate/longer-standing timing issue in USB enumeration at boot that the R36.5.x change happened not to fix either way. Any guidance on:
- Whether there’s a supported way to force a USB rescan early in boot (devicetree property, kernel cmdline param, or a systemd hook) instead of requiring a physical replug or external hub power-cycle.
- Whether this is being tracked as the same bug internally as the threads above, so we know whether to expect a fix in a future R36.5.x point release.
Happy to share full boot logs (dmesg / journalctl -k -b 0) if useful.