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

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