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

[djraszit]

Hi Michal, Oliver,

I have just completed another experiment which seems to make the VBUS
behaviour considerably more suspicious.

I inserted a Genesys Logic USB 3.x hub (05e3:0626) between the
Raspberry Pi 4 and the original JMS578 enclosure (0080:a001).

The topology is:

RPi4 / VL805
-> Genesys Logic 05e3:0626
-> JMS578 0080:a001

The JMS578 still operates using UAS at SuperSpeed (5000M), so the hub
does not cause a fallback to USB 2.0 or usb-storage/BOT.

This particular Genesys hub can operate either bus-powered or from an
external 5 V supply. I have previously checked its power wiring: the
external 5 V input is connected directly to the downstream USB VBUS
rails, while VBUS from the host is connected through a diode.

Therefore, with the external supply connected, downstream VBUS remains
supplied independently of the Pi.

This gave me a useful A/B test while keeping the same hub, port,
cable, JMS578 and USB3/UAS topology.

First I used the Genesys hub without its external supply, i.e. bus-powered.

With:

USB_MSD_PWR_OFF_TIME=1000

and starting from a known GOOD state, the first reboot immediately
reproduced the BAD-data state:

Alternate GPT is invalid, using primary GPT.

The direct test read also returned the known BAD hash.

I then recovered the JMS578 to a known GOOD state and connected the
external supply to the same Genesys hub. No USB cables or ports were
changed.

With USB_MSD_PWR_OFF_TIME=1000 and the Genesys hub externally powered,
I performed five consecutive reboots.

All five were GOOD.

I then changed the bootloader setting to:

USB_MSD_PWR_OFF_TIME=0

while leaving the same Genesys hub externally powered.

I performed several more consecutive reboots. These were also all
GOOD. I could reproduce neither the BAD-data state nor the "Cannot
enable" enumeration failure which occurred previously when VBUS to the
JMS578 was supplied by the Pi.

So the current comparison is:

USB_MSD_PWR_OFF_TIME=1000, bus-powered Genesys:
-> BAD-data after reboot
-> invalid alternate GPT
-> BAD direct-read hash

USB_MSD_PWR_OFF_TIME=1000, externally powered Genesys:
-> 5 consecutive reboots GOOD

USB_MSD_PWR_OFF_TIME=0, VBUS supplied by the Pi:
-> previously reproducible "Cannot enable" after consecutive reboots

USB_MSD_PWR_OFF_TIME=0, externally powered Genesys:
-> several consecutive reboots GOOD

The important control is that simply inserting the Genesys hub does
not prevent the failure. The same hub in bus-powered mode reproduced
the BAD-data state immediately. The failures disappeared when I
supplied the same hub externally, keeping downstream VBUS continuously
powered during Pi reboots.

This seems particularly interesting together with the VBUS waveform I
reported previously:

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

I still don't think this proves that the ~130 ms interval itself is
the cause, because an externally powered hub may also affect reset or
link behaviour. However, continuously supplying downstream VBUS has so
far prevented both observed failure modes.

One additional clarification about my GOOD/BAD test: I am no longer
using LUKS, device-mapper or ext4 to determine the state.

I read a stable 512-byte sector directly from the USB block device,
specifically the last sector of the MP3_FILMY partition, using:

MP3_FILMY_SECTORS=$(sudo blockdev --getsz /dev/disk/by-label/MP3_FILMY)
sudo dd if=/dev/disk/by-label/MP3_FILMY count=1 bs=512
skip=$((MP3_FILMY_SECTORS-1)) status=none iflag=direct | sha256sum

The known GOOD hash is:

4755035f51940c4bbe13c596ba55e4eb278c13d9a24cfca7a9530e1f788f71eb

and the reproducible BAD-data hash is:

4fc3036031ecaa505dc82e38ca996d9615d12780fded2ebad35fb58e44f7efde

So LUKS, device-mapper and ext4 are no longer involved in determining
whether the returned data are GOOD or BAD.

Regards,
djraszit

czw., 17 wrz 2026 o 18:56 Michal Pecio <michal.pecio@xxxxxxxxx> napisał(a):
>
> On Thu, 17 Sep 2026 18:02:02 +0200, djraszit wrote:
> > 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
>
> > 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.
>
> So it's a boot issue. I think it would make sense to determine whether
> the problem is caused by bootloader actions or the kernel.
>
> Is it possible to configure the bootloader to wait a few seconds before
> booting the kernel and connect or disconnect the device during this
> time, or to never boot the kernel at all so that the device can be
> disconnected and tested on another machine?
>
> If it's the bootloader, and things seem to be going in this direction,
> then you will need to sort this out with the vendor, obviously.
>
> > 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.
>
> Thanks, that's all I wanted to know. It's some other xHCI controller.
>
> (I looked it up, it seems RP1 uses Synopsys IP).
>
> Regards,
> Michal