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

[djraszit]

Hi Michal, Oliver,

I performed the two shutdown/boot separation tests suggested by
Michal. All tests started with the enclosure in a known GOOD state.

First:

shutdown Pi with the enclosure connected
-> disconnect USB after shutdown
-> boot the Pi without the enclosure
-> wait for Linux to boot completely
-> reconnect USB

I repeated this three times. All three tests were GOOD: no "Alternate
GPT is invalid" message and the test block had the correct hash.

Then I tested:

disconnect USB while the Pi is running
-> shutdown the Pi
-> connect USB while the Pi is off
-> boot

The first attempt was GOOD. On the second attempt the enclosure failed
during USB initialization with:

Cannot enable. Maybe the USB cable is bad?

I also tested consecutive normal reboots with the enclosure connected.
This was repeatable: the first reboot was GOOD, while the second
reboot resulted in "Cannot enable".

There is another interesting and repeatable difference depending on
the Raspberry Pi bootloader setting USB_MSD_PWR_OFF_TIME.

With:

USB_MSD_PWR_OFF_TIME=0

I do not currently reproduce the state where the enclosure enumerates
successfully but returns incorrect data. Instead, after consecutive
reboots I reproducibly get the "Cannot enable" failure described
above.

After changing it back to:

USB_MSD_PWR_OFF_TIME=1000

I repeated the test twice, starting from a known GOOD state each time.
A reboot reproducibly resulted in the enclosure enumerating normally,
but:

Alternate GPT is invalid, using primary GPT.

and the previously tested block returned the BAD hash.

Interestingly, in this BAD-data state it is sufficient to switch the
enclosure off and on using its power switch, with USB still connected.
After that, the data are correct again.

I also observed the USB VBUS during reboot with an oscilloscope. With
USB_MSD_PWR_OFF_TIME=1000, the VBUS sequence is not simply an off
period followed by power being restored. During reboot I observe
approximately:

VBUS off for several seconds
-> VBUS on for about 130 ms
-> VBUS off again for about 1 second
-> VBUS on

The timings are approximate oscilloscope measurements, but the short
~130 ms VBUS-on interval between the two off periods is clearly
visible and repeatable.

I do not know whether this sequence is related to the JMS578 failure,
but it may be relevant given that changing USB_MSD_PWR_OFF_TIME
changes the failure mode reproducibly.

So at the moment I appear to have at least two reproducible failure modes:

USB_MSD_PWR_OFF_TIME=0
-> after consecutive reboots: USB enumeration failure ("Cannot enable")

USB_MSD_PWR_OFF_TIME=1000
-> enclosure enumerates, but UAS reads incorrect data
(invalid alternate GPT and BAD hash)

The tests where the enclosure participated in shutdown but was absent
during the subsequent boot were consistently GOOD (3/3). Conversely,
it can fail when it was disconnected before shutdown but connected
again before boot. This seems to make the boot sequence more
suspicious than the shutdown sequence.

Regarding Oliver's suggestion to abruptly remove power from the
running Pi: I would prefer not to perform that test on this particular
system at the moment. This Raspberry Pi 4 is also my router and file
server and has several other disks attached, so an uncontrolled power
loss would introduce a risk of filesystem damage to the system or the
other storage devices. If this test turns out to be important, I can
consider preparing a separate/minimal setup for it rather than doing
it on the production system.

Regarding the Raspberry Pi 5 test: yes, the enclosure was connected to
USB 3.0/SuperSpeed. The Pi 5 uses the RP1 southbridge rather than the
VL805 used by the Pi 4. On my Pi 5 Linux exposes two xHCI controllers,
xhci-hcd.0 and xhci-hcd.1, each with a SuperSpeed bus at 5000M. I can
reconnect the enclosure and provide the exact lsusb -t output with the
JMS578 attached if useful.

Regards,
djraszit

czw., 17 wrz 2026 o 12:23 Oliver Neukum <oneukum@xxxxxxxx> napisał(a):
>
>
>
> On 16.09.26 20:47, Michal Pecio wrote:
> > On Wed, 16 Sep 2026 19:56:25 +0200, djraszit wrote:
>
> > 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
>
> Maybe it would be worthwhile to shut the RPi down the hard
> way, that is by suddenly depriving it of power.
>
> > 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
>
> But then why does it work at all? You'd have to assume that
> the second boot crashes the device.
>
> > 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.
>
>         Regards
>                 Oliver
>