Hi Tom,
Apologies for late reply. Somehow missed the mail.
Upon analysis, it seems the most likely root cause is Tony's 238GB disk
triggers the CONFIG_SYS_64BIT_LBA code path in scsi_read function. Any
read beyond block 268,435,455 blocks enters this path.
'blks' is decremented both inside the 64-bit LBA block AND after
successful scsi_exec(), causing incorrect block count tracking and (most
likely) the data abort observed.
The fix is to remove 'blks -= blocks;' from inside the
CONFIG_SYS_64BIT_LBA block in scsi_read() function.
Hi Tony, can you please check with this change?
Tom, shall I raise a new patch for this now?
Regards,
Balaji
On 12/16/2025 10:36 PM, Tom Rini wrote:
On Fri, Dec 12, 2025 at 08:50:56AM -0600, Tom Rini wrote:
On Mon, Dec 08, 2025 at 06:53:52PM -0800, Tony Dinh wrote:
This reverts commit b32dda34506b4f486bc803d0c7251f987edd2455.
Currently, scsi is broken and causes data abort. I did a bisect and found
that this commit was the cause. Reverting it and scsi is working again.
=== Error Log with data abort
U-Boot 2026.01-rc4-tld-1-g0e0a198a68be (Dec 08 2025 - 17:42:05 -0800)
Synology DS116
DS116> scsi reset
Reset SCSI
scanning bus for devices...
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
Device 0: (0:0) Vendor: ATA Prod.: FUJITSU MHY2250B Rev: 890B
Type: Hard Disk
Capacity: 238475.1 MB = 232.8 GB (488397169 x 512)
DS116> ext2ls scsi 0:1 /boot
data abort
pc : [<3ffa5d3e>] lr : [<3ffc1515>]
sp : 3fb65ad8 ip : 0000000c fp : 3fb7f220
r10: 00002710 r9 : 3fb6aed0 r8 : 3fb85e40
r7 : f10a8100 r6 : 000003e8 r5 : 000003e8 r4 : 3fb65ae0
r3 : e38e39c1 r2 : 00000000 r1 : 3fb65ae0 r0 : 00931767
Flags: Nzcv IRQs off FIQs off Mode SVC_32 (T)
Code: 3ffd b510 6803 460c (6bdb) 681b
Signed-off-by: Tony Dinh <[email protected]>
Any comments Balaji ?
Again, any comments Balaji? I'm otherwise inclined to take this revert
this week and sort things out again in the next branch / post v2026.01.
