Re: [BUG] uas: JMS578 returns reproducibly incorrect data after host reboot

[Michal Pecio <michal.pecio@gmail.com>]

On Wed, 16 Sep 2026 19:56:25 +0200, djraszit wrote:
> First, I tested the original enclosure (0080:a001, apparently JMS578)
> connected to a USB 2.0 port of the Raspberry Pi 4.
> 
> Interestingly, it still uses UAS

Yes, UAS can run on USB 2.0. It uses a custom protocol to multiplex
requests over ordinary bulk pipes, without USB 3.0 "streams".

So it's yet another different protocol and a different speed.

> RPi4 + USB3/SuperSpeed + UAS  -> BAD after reboot
> RPi4 + USB3/SuperSpeed + BOT  -> GOOD
> RPi4 + USB2/480M       + UAS  -> GOOD

> As a control test, while the original enclosure was in a known-good
> state I manually disconnected its USB cable for approximately three
> seconds and reconnected it. This did NOT trigger the bad state.

> enclosure in GOOD state
> -> shutdown Raspberry Pi 4
> -> remove Raspberry Pi power completely
> -> wait several seconds
> -> apply Raspberry Pi power
> -> wait for complete boot
> -> test data  
> 
> The enclosure remained powered and physically connected to the
> Raspberry Pi during this test.
> 
> The result was BAD.

> enclosure in GOOD state
> -> disconnect USB
> -> reboot Raspberry Pi 4
> -> wait until the Pi has completely booted
> -> reconnect USB  
> 
> The result was GOOD.

Looks like JMS578 doesn't like being connected to a booting Pi 4.

Or maybe it's shutdown? What happens if you:

- disconnect, shutdown, connect, boot
- shutdown, disconnect, boot, connect

If the problem is boot (second case works, first case fails), then
I wonder if it's the firmware or the kernel. Maybe you could plug
the disk after the kernel beigns booting, but before xhci_hcd loads?
You could blacklist it if it's a module, or bind pci-stub to VL805
to prevent automatic xhci_hcd activation and widen the time window.

> With the original enclosure, after the bad state had been triggered by
> a Raspberry Pi 4 reboot, I disconnected its USB cable and connected it
> to another Linux computer without power-cycling the enclosure. The
> device could still be accessed there, but it returned the same
> incorrect data.
> 
> For both JMicron devices there is also an interesting recovery behaviour.
> 
> Simply disconnecting and reconnecting USB does not recover them.
> 
> Switching the enclosure/dock off and on while the USB cable remains
> connected does not recover them either.
> 
> Recovery requires both

Clearly the persistent breakage occurs inside JMS578. Looks like
either external PSU or VBUS suffices to maintain this state.

So the chip is somewhat dodgy and the only hope is that maybe we
could avoid triggering this failure.

And it seems to be the chip, not the disk, because only USB 3.0
UAS is broken. Though no harm in trying other HDD to be sure.

> Finally, I also tested the original enclosure on a Raspberry Pi 5. I
> performed several reboots with it connected and could not reproduce
> the corruption.

That was USB 3.0? What's the USB controller on this board?

Regards,
Michal