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

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

[Oliver Neukum]

On 13.09.26 16:38, djraszit wrote:
> The same correct value is also obtained when the enclosure and disk are connected to another Linux computer.

Hi,

thank you for this valuable and comprehensive bug report.
Just to clarify, does the quote from above indicate that
the device returns correct data on other systems after
reboot or does it mean that you verified that the disk
holds the correct content by attaching it to another system?

	Regards
		Oliver

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

[djraszit]

wt., 15 wrz 2026 o 08:50 Oliver Neukum <oliver@neukum.org> napisał(a):
>
> On 14.09.26 20:44, djraszit wrote:
> > The most interesting result to me is therefore that, once the problem
> > has been triggered, the same disk and the same JMS578 return different
> > data depending on whether UAS or usb-storage/BOT is used, and
> > switching back to UAS reproduces exactly the same incorrect block
> > contents again.
> >
> > Please let me know if there are any additional traces, usbmon
> > captures, dynamic-debug output, or kernel instrumentation that would
> > be useful. I can reproduce the problem and perform further tests.
>
> Hi,
>
> thank you. You did testing on a very strange bug.
> However I need to request that you please do not remove the list from CC.
> People need to see our reasoning.
>
> Secondly, at this point we need to rule out that the Raspberry
> firmware does things to the enclosure. Could you please
>
> 1. suspend the raspberry with the drive attached
> 2. unplug the drive
> 3. resume the Raspberry
> 4. replug the drive
> 5. test for corruption
>
> in that order? That way we can determine whether the issue happens
> during suspension or resumption.
>
>         Regards
>                 Oliver
>

Hi Oliver,

I performed some additional tests.

Unfortunately I cannot currently perform the suspend test on this
Raspberry Pi 4 because my custom kernel was built without suspend
support:

```
# CONFIG_SUSPEND is not set
```

/sys/power/state is therefore empty.

I can rebuild the kernel with suspend support if this particular test
is still important.

However, I performed several other tests which may be relevant.

First, I tested the same JMS578 enclosure on a Raspberry Pi 5. I
performed several reboots with the enclosure continuously connected
and powered. The data remained correct after every reboot.

I also tested suspend/resume on a Linux laptop with the same enclosure
and the data remained correct there as well.

I additionally tested switching transport modes while the JMS578 was
in a known good state:

```
UAS -> BOT -> UAS
```

The same test block returned the correct hash in all three cases.

This is different from the previously observed state after an affected
Raspberry Pi 4 reboot:

```
UAS -> BAD
BOT -> GOOD
UAS -> BAD
```

so changing between UAS and BOT by itself does not appear to create
the bad state.

I then investigated the Raspberry Pi 4 EEPROM bootloader USB power handling.

I tested:

```
USB_MSD_PWR_OFF_TIME=0
```

and also:

```
USB_MSD_PWR_OFF_TIME=5000
```

With 5000 I could visibly confirm on another USB-powered device that
USB power was actually removed for approximately five seconds during
reboot.

The longer power-off did not fix the incorrect reads.

With USB_MSD_PWR_OFF_TIME=0 I also encountered a reboot where the
JMS578 could no longer enumerate at all. Replugging USB twice did not
recover it, and power-cycling the enclosure while USB remained
connected did not recover it either. Only disconnecting USB and
switching off the enclosure, followed by reconnecting/powering it
again, restored communication.

Finally, I explicitly removed USB mass-storage boot from the boot order:

```
BOOT_ORDER=0xf1
```

The JMS578 still returned incorrect data after reboot.

So at this point the problem does not appear to require USB-MSD boot
probing, and increasing the configurable USB power-off interval to
five seconds does not prevent it.

The behaviour still appears specific to rebooting this Raspberry Pi 4.
The Raspberry Pi 5 and the Linux laptop do not reproduce it.

Regards,
djraszit

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

[Michal Pecio]

Hi,

This looks bizarre and it isn't even obvious which device to blame.
Have you tried any of these things?

Disconnect the USB cable and connect it back, without powering down
the disk or the Pi. Can this fix it? Can this break it when good?

In good state: disconnect, reboot the Pi, connect. Does this break?

In bad state: disconnect and connect it to another machine without
power cycling. Still broken?

Regards,
Michal

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

[djraszit]

Hi,

I have done several more tests and I think I need to correct one of my
earlier assumptions. Initially I suspected that UAS itself might be
involved, but the new results show that UAS alone is not sufficient to
reproduce the problem. The failure appears to be much more
specifically related to the Raspberry Pi 4 SuperSpeed USB path, or to
an interaction between it and these JMicron bridges.

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:

```
Class=Mass Storage, Driver=uas, 480M
```

I performed multiple reboots in this configuration. I did not get the
"Alternate GPT is invalid" message and the known test block remained
correct:

```
6b716692a9eecccf9ab693a6419dc7325b3072c6ecf8499ffa2a1e4bd126b483
```

This seems important because the same enclosure connected through USB
3.0/SuperSpeed with UAS can return reproducibly incorrect data after a
Raspberry Pi 4 reboot, whereas UAS over USB 2.0 remains correct.

I had also previously tested USB 3.0/SuperSpeed with BOT forced via:

```
usb-storage.quirks=0080:a001:u
```

In that configuration the enclosure used usb-storage instead of UAS
and the data remained correct after reboot.

So the combinations tested so far are approximately:

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

There is also the earlier result from dynamically switching transport
after a bad state had already been triggered:

```
UAS -> BAD
BOT -> GOOD
UAS -> the same BAD data again
```

Therefore neither UAS alone nor SuperSpeed alone appears sufficient to
explain all of the observations.

I also measured USB VBUS during reboot with an oscilloscope.

With:

```
USB_MSD_PWR_OFF_TIME=0
```

VBUS disappears for approximately 3.17 seconds during reboot.

During a normal cold start after "shutdown now", removal of Raspberry
Pi power, and subsequent application of power, I did not observe any
unusual spikes on VBUS. The USB voltage simply appeared after a delay.

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.

I also tested a complete Raspberry Pi 4 power cycle:

```
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.

So the problem is not specific to a warm reboot. Starting a completely
power-cycled Raspberry Pi 4 while the already-powered enclosure
remains connected can also trigger the problem.

In contrast, I performed the test suggested by Michal:

```
enclosure in GOOD state
-> disconnect USB
-> reboot Raspberry Pi 4
-> wait until the Pi has completely booted
-> reconnect USB
```

The result was GOOD. There was no "Alternate GPT is invalid" message
and the test block had the correct hash.

I also tried removing the SCSI device before reboot with:

```
echo 1 > /sys/block/sdX/device/delete
```

while leaving the USB device physically connected.

This did not prevent the problem. After reboot the original enclosure
again produced "Alternate GPT is invalid" and incorrect data.

I then tested a second, different docking station which also uses a
JMicron bridge:

```
152d:0578
Product: USB3.0 HDD DOCK
Manufacturer: JMicron
```

This device shows a different failure mode, but it is also affected by
Raspberry Pi 4 reboots on USB 3.0/SuperSpeed.

After recovering the docking station it enumerated normally as SuperSpeed/UAS:

```
JMicron USB3.0 HDD DOCK
152d:0578
Driver=uas, 5000M
```

The disk was detected correctly, there were no GPT errors, and the
known test block returned the correct hash:

```
6b716692a9eecccf9ab693a6419dc7325b3072c6ecf8499ffa2a1e4bd126b483
```

After another Raspberry Pi 4 reboot, however, this second JMicron
device could no longer enumerate on the SuperSpeed bus. The kernel
repeatedly reported:

```
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
```

The device was completely absent from lsusb and no block device was created.

I recovered the docking station, verified that it again worked
normally and returned the correct hash, and repeated the reboot test.
The failure occurred again.

I have now also performed Michal's test with this second 152d:0578
dock while it was in that failed state.

Without switching off or otherwise power-cycling the dock, I
disconnected only its USB cable from the Raspberry Pi 4 and connected
it to a Linux laptop.

There was no USB activity at all on the laptop: no new messages
appeared in dmesg and the device did not enumerate.

I then disconnected it from the laptop and connected it back to the
Raspberry Pi 4, still without power-cycling the dock.

Again there was no USB activity at all and no new dmesg messages.

Therefore, in this case the failed state follows the JMicron dock to
another host and survives USB disconnection/reconnection. It is not
simply a bad state retained by the Raspberry Pi 4 USB controller.

This is similar to what I had already observed with the original
0080:a001 enclosure, although its failure mode is different.

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:

```
disconnect USB
+ switch off the enclosure/dock
```

followed by powering it again and reconnecting USB.

This suggests that the failure state persists somewhere in the device
while either side is still providing enough power to retain that
state.

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.

I also tested suspend/resume with the enclosure on a Linux laptop and
the reads remained correct.

So the current observations can be summarized as:

```
Original 0080:a001 enclosure:

RPi4 + USB3/SuperSpeed + UAS
    -> reboot/cold boot can cause incorrect reads
    -> "Alternate GPT is invalid"
    -> incorrect block contents

RPi4 + USB3/SuperSpeed + BOT
    -> GOOD

RPi4 + USB2/480M + UAS
    -> multiple reboots tested
    -> GOOD

RPi4 reboot while enclosure is physically disconnected,
followed by connection after Linux has booted
    -> GOOD

Bad state -> move enclosure to another Linux host
without power-cycling
    -> same incorrect data on the other host


Second JMicron 152d:0578 dock:

RPi4 + USB3/SuperSpeed + UAS
    -> reboot can leave the device unable to enumerate
    -> repeated "Cannot enable. Maybe the USB cable is bad?"

Bad state -> move dock to another Linux host
without power-cycling
    -> still completely unresponsive
    -> no USB event on the other host


Other tests:

Original enclosure + RPi5 USB3
    -> several reboots
    -> GOOD

Original enclosure + laptop suspend/resume
    -> GOOD

approximately 3 seconds manual USB disconnect/reconnect
    -> does not create the bad state

SCSI device/delete before RPi4 reboot
    -> does not prevent the bad state

complete RPi4 power-off/cold boot while the powered
enclosure remains connected
    -> can still produce BAD
```

The new results therefore change my earlier interpretation. UAS by
itself does not appear to be the cause, because the original enclosure
operates correctly with UAS at 480M and survives multiple Raspberry Pi
4 reboots.

At the same time, the fact that the failed state follows both JMicron
devices to another host indicates that the persistent failed state is
in the enclosure/dock rather than being only a retained state of the
Raspberry Pi USB controller.

What I still cannot determine is what initially puts the JMicron
bridges into that state. At present it appears to require some
interaction with the Raspberry Pi 4 SuperSpeed USB path during
boot/reboot. I do not know whether the root cause is on the Raspberry
Pi 4/VL805 side, in the JMicron firmware, or in the interaction
between the two.

Please let me know what additional traces or tests would be most useful.

Regards,
djraszit

wt., 15 wrz 2026 o 23:38 Michal Pecio <michal.pecio@gmail.com> napisał(a):
>
> Hi,
>
> This looks bizarre and it isn't even obvious which device to blame.
> Have you tried any of these things?
>
> Disconnect the USB cable and connect it back, without powering down
> the disk or the Pi. Can this fix it? Can this break it when good?
>
> In good state: disconnect, reboot the Pi, connect. Does this break?
>
> In bad state: disconnect and connect it to another machine without
> power cycling. Still broken?
>
> Regards,
> Michal
>

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

[Michal Pecio]

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

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

[Oliver Neukum]

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

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@suse.com> 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
>

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

[Michal Pecio]

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

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@gmail.com> 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

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

[djraszit]

Subject: JMS578 USB-SATA bridge returns reproducibly incorrect data
with UAS after host reboot

Hello,

I would like to report a possible issue involving the Linux UAS driver
and a JMS578-based USB-to-SATA bridge. I am not yet sure whether the
root cause is in the UAS driver, xHCI interaction, or the JMS578
firmware, but I have been able to reproduce the problem and isolate it
to UAS operation.

Hardware / system

Host:

Raspberry Pi 4

Linux 6.18.45-v8_1khz+

aarch64 kernel, 32-bit armhf userspace

USB-SATA bridge:

Bus 002 Device 005: ID 0080:a001 Unknown JMS578 based SATA bridge

The device identifies itself as:

Product: External USB 3.0
Manufacturer: TOSHIBA
SerialNumber: 2015033100081

It is connected through a Realtek USB 3.0 hub:

0bda:0411 Realtek Semiconductor Corp. Hub

The SATA disk contains a LUKS2 container with an ext4 filesystem. The
enclosure has its own external power supply and remains powered during
a reboot of the Raspberry Pi.

Problem

When the Raspberry Pi is rebooted while the USB-SATA enclosure remains
powered, the disk is detected normally using UAS:

scsi host2: uas
sd 2:0:0:0: [sdc] 1953525168 512-byte logical blocks
sd 2:0:0:0: [sdc] 4096-byte physical blocks

There are no obvious I/O errors, but some sectors are read with
incorrect contents.

This initially appeared to be severe ext4 filesystem corruption. For example:

EXT4-fs error (device dm-3): ext4_find_extent:944:
inode #8: comm mount: pblk 121667583 bad header/extent:
invalid magic - magic 7426, entries 15446, max 59087(0), depth 39757(0)

jbd2_journal_init_inode: Cannot locate journal superblock
EXT4-fs (dm-3): Could not load journal inode

However, the filesystem itself is not corrupted.

Reproducible block test

I opened the LUKS device read-only and repeatedly read ext4 block 121667583:

cryptsetup open --readonly /dev/disk/by-label/MP3_FILMY MP3_FILMY_encrypted

dd if=/dev/mapper/MP3_FILMY_encrypted \
   bs=4096 skip=121667583 count=1 status=none | sha256sum

With UAS after a Raspberry Pi reboot, the result is consistently:

66c32ba5b97394b491efb79e11fcfeae2a9040aa237beb51e09afee342903dc2

I repeated this read many times and always received exactly the same
incorrect hash. Therefore this does not appear to be random USB
transmission corruption.

After physically powering the USB-SATA enclosure off and back on, the
same block reads as:

6b716692a9eecccf9ab693a6419dc7325b3072c6ecf8499ffa2a1e4bd126b483

This is the correct value.

The same correct value is also obtained when the enclosure and disk
are connected to another Linux computer.

USB resets do not recover the device

I tested a USB device reset. The kernel reported:

usb 2-2.2: reset SuperSpeed USB device number 9 using xhci_hcd

but the block still returned the incorrect hash:

66c32ba5b97394b491efb79e11fcfeae2a9040aa237beb51e09afee342903dc2

I also used per-port power switching with uhubctl. The kernel
performed a complete USB disconnect and re-enumeration:

usb 2-2.2: USB disconnect, device number 5
...
usb 2-2.2: new SuperSpeed USB device number 9 using xhci_hcd
...
scsi host2: uas
...
sd 2:0:0:0: [sdc] Attached SCSI disk

but the incorrect block contents remained.

Because the enclosure is externally powered, the JMS578 itself
apparently remains powered during these USB-side resets.

Only physically removing power from the enclosure restored correct
reads while UAS was in use.

Disabling UAS fixes the problem

I then disabled UAS specifically for this bridge using:

usb-storage.quirks=0080:a001:u

After rebooting the Raspberry Pi, while leaving the enclosure
continuously powered, lsusb -t showed:

Class=Mass Storage, Driver=usb-storage, 5000M

instead of:

Class=Mass Storage, Driver=uas, 5000M

I then repeated exactly the same LUKS block test.

The result was immediately correct:

6b716692a9eecccf9ab693a6419dc7325b3072c6ecf8499ffa2a1e4bd126b483

I also ran a complete read-only ext4 check:

e2fsck -fn /dev/mapper/MP3_FILMY_encrypted

It successfully completed all five passes without filesystem errors:

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

MP3_FILMY: 18368/61046784 files (19.3% non-contiguous),
71945629/244186289 blocks

The only messages were several harmless suggestions that extent trees
"could be shorter".

Summary

The behaviour is therefore reproducible as follows:

JMS578 enclosure is externally powered and remains powered.

Linux uses the uas driver.

Reboot the Raspberry Pi without power-cycling the enclosure.

The disk is detected normally, but at least some reads return
reproducibly incorrect data.

USB reset does not fix it.

USB disconnect/re-enumeration does not fix it.

Physically power-cycling the JMS578 enclosure fixes it.

Disabling UAS with usb-storage.quirks=0080:a001:u also fixes it, even
without power-cycling the enclosure.

This is particularly dangerous because the problem does not
necessarily produce an I/O error. Valid but incorrect data is returned
to the block layer, causing higher layers such as dm-crypt and ext4 to
interpret the filesystem as corrupted.

I would be happy to perform additional tests, enable UAS/SCSI/xHCI
debugging, collect usbmon traces, provide kernel logs, or test a patch
if that would help determine whether this is a Linux UAS issue or a
firmware quirk in this JMS578 implementation.

Regards