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

[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