Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90804 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1120831: [regression] failed command: READ FPDMA QUEUED after boot for INTEL SSDSC2KG480G8, XCV10120 after 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Wolf <snow.wolf.29@proton.me> - 2026-01-14 16:20 +0100
    Bug#1120831: [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> - 2026-01-14 17:50 +0100
      Bug#1120831: [regression] failed command: READ FPDMA QUEUED after boot for INTEL SSDSC2KG480G8, XCV10120 after 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Wolf <snow.wolf.29@proton.me> - 2026-01-15 06:40 +0100
        Bug#1120831: [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> - 2026-01-16 15:10 +0100
          Bug#1120831: [regression] failed command: READ FPDMA QUEUED after boot for INTEL SSDSC2KG480G8, XCV10120 after 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") Wolf <snow.wolf.29@proton.me> - 2026-01-16 16:10 +0100

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

On Wednesday, 14 January 2026 at 16:17, Niklas Cassel <cassel@kernel.org> wrote:

>
>
> Hello Salvatore,
>
> On Wed, Jan 14, 2026 at 12:47:45PM +0100, Salvatore Bonaccorso wrote:
>
> > A user reported a regression affecting his devices after 9b8b84879d4a
> > ("block: Increase BLK_DEF_MAX_SECTORS_CAP") which maybe needs a
> > similar quirk like 2e9832713631 ("ata: libata-core: Quirk DELLBOSS VD
> > max_sectors").
>
>
> The drive:
>
> > Dec 10 18:56:03 kernel: ata1.00: Model 'INTEL SSDSC2KG480G8', rev 'XCV10120', applying quirks: zeroaftertrim
> > Dec 10 18:56:03 kernel: ata1.00: ATA-10: INTEL SSDSC2KG480G8, XCV10120, max UDMA/133
>
>
> The SATA controller:
> 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake Mobile PCH SATA AHCI Controller [8086:a353] (rev 10) (prog-if 01 [AHCI 1.0])
> DeviceName: Onboard - SATA
> Subsystem: Dell Device [1028:0924]
>
>
> Perhaps the user could run:
> https://github.com/floatious/max-sectors-quirk/blob/master/find-max-sectors.sh
>
> So we could find which max sectors value we should quirk the device with,
> since while the drive obviously chokes on a command of size 4 MiB / 8192
> sectors, it might be able to handle something larger than 1280 KiB / 2560
> sectors.
>
>
> Kind regard,
> Niklas

Hi,

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


Regards,
Wolf

[toc] | [next] | [standalone]

#90807

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

[toc] | [prev] | [next] | [standalone]

#90811

On Wednesday, 14 January 2026 at 18:25, Niklas Cassel <cassel@kernel.org> wrote:

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


Hi, Niklas

Udev rule

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="4096"

is not working.


Regards,
Wolf

[toc] | [prev] | [next] | [standalone]

#90835

Hello Wolf,

On Thu, Jan 15, 2026 at 05:29:28AM +0000, Wolf wrote:
> Hi, Niklas
> 
> Udev rule
> 
> ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="4096"
> 
> is not working.

Ok, since you seem to be able to reproduce it so easily,
then perhaps try with different values here, e.g.
1280 2048 3072 4095

and tell us the largest one that is working, and we could
add a quirk for the device with the highest value that is
working for you.


Kind regards,
Niklas

[toc] | [prev] | [next] | [standalone]

#90837

On Friday, 16 January 2026 at 15:59, Niklas Cassel <cassel@kernel.org> wrote:

> 
> 
> Hello Wolf,
> 
> On Thu, Jan 15, 2026 at 05:29:28AM +0000, Wolf wrote:
> 
> > Hi, Niklas
> > 
> > Udev rule
> > 
> > ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="4096"
> > 
> > is not working.
> 
> 
> Ok, since you seem to be able to reproduce it so easily,
> then perhaps try with different values here, e.g.
> 1280 2048 3072 4095
> 
> and tell us the largest one that is working, and we could
> add a quirk for the device with the highest value that is
> working for you.
> 
> 
> Kind regards,
> Niklas


Hello, Niklas


The largest working value is 4095.


Regards,
Wolf

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web