Re: [regression] failed command: READ FPDMA QUEUED after boot for INTEL SSDSC2KG480G8, XCV10120 after 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP")

[Niklas Cassel <cassel@kernel.org>]

Hello Wolf,

On Wed, Jan 14, 2026 at 03:11:50PM +0000, Wolf wrote:
> Here is find-max-sectors.sh output:
> 
> Drive model:
> INTEL SSDSC2KG480G8
> 
> Drive firmware:
> XCV10120
> 
> SATA / AHCI controller:
> 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller [8086:a353] (rev 10)
> 
> Drive values before running the test:
> /sys/block/sda/queue/max_hw_sectors_kb:32767
> /sys/block/sda/queue/max_sectors_kb:1280
> /sys/block/sda/queue/read_ahead_kb:128
> 
> Running test with max_sectors 128 KiB
> Test: PASS
> 
> Running test with max_sectors 1024 KiB
> Test: PASS
> 
> Running test with max_sectors 2048 KiB
> Test: PASS
> 
> Running test with max_sectors 3072 KiB
> Test: PASS
> 
> Running test with max_sectors 4095 KiB
> Test: PASS
> 
> Running test with max_sectors 4096 KiB
> Test: PASS

It is quite unexpected that 4096 KiB passes.

find-max-sectors.sh performs reads.

The commands that timed out according to dmesg shared were
also reads:

Dec 10 18:58:49 kernel: ata1.00: failed command: READ FPDMA QUEUED
Dec 10 18:58:49 kernel: ata1.00: cmd 60/00:18:50:4a:4c/20:00:0c:00:00/40 tag 3 ncq dma 4194304 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

And also of size 4194304 == 4096 KiB.


The script has been able to detect different limits for other
"broken" drives, and was used to get the quirk value for e.g.
commit 2e9832713631 ("ata: libata-core: Quirk DELLBOSS VD max_sectors"),
so I wonder why it is not workin here (why 4 MiB reads passes).

Damien, ideas?


Kind regards,
Niklas