Bug#1120831: Acknowledgement (eslinux-image-6.17.8+deb14-amd64: failed command: READ FPDMA QUEUED after boot)
Hi,
On Wed, Jan 14, 2026 at 11:10:42AM +0000, Wolf wrote:
>
>
> On Wednesday, 14 January 2026 at 12:14, Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> >
> >
> > Hi Wolf,
> >
> > On Wed, Jan 14, 2026 at 09:17:27AM +0000, Wolf wrote:
> >
> > > On Sunday, 11 January 2026 at 22:15, Salvatore Bonaccorso carnil@debian.org wrote:
> > >
> > > > Hi,
> > > >
> > > > So there is a similar (but not identical, and different disks) report
> > > > at https://bugzilla.kernel.org/show_bug.cgi?id=220693 pointing at the
> > > > same commit 9b8b84879d4a ("block: Increase BLK_DEF_MAX_SECTORS_CAP") .
> > > >
> > > > That particular one was fixed with 2e9832713631 ("ata: libata-core:
> > > > Quirk DELLBOSS VD max_sectors").
> > > >
> > > > Let's see if your report rings something to upstream.
> > > >
> > > > Regards,
> > > > Salvatore
> > >
> > > Hi,
> > >
> > > Workaround: add the rule
> > >
> > > ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sda", ATTR{queue/max_sectors_kb}="1280"
> > >
> > > in /etc/udev/rules.d/99-sda-max-sectors.rules.
> > >
> > > It works on linux/6.18.3+deb14-amd64.
> >
> >
> > I think we will need a similar quirk as in the above bug for your
> > device. Can you please test the following patch?
> >
> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > index 09d8c035fcdf..8434110a4962 100644
> > --- a/drivers/ata/libata-core.c
> > +++ b/drivers/ata/libata-core.c
> > @@ -4108,6 +4108,7 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
> > /
> > { "LITEON CX1-JB-HP", NULL, ATA_QUIRK_MAX_SEC_1024 },
> > { "LITEON EP1-", NULL, ATA_QUIRK_MAX_SEC_1024 },
> > + { "INTEL SSDSC2KG480G8", "XCV10120", ATA_QUIRK_MAX_SEC_1024 },
> >
> > /
> > * These devices time out with higher max sects.
> >
> > I will forward the bug upstream and keep you in the loop, but would be
> >
> > Regards,
> > Salvatore
>
> Hi,
>
> The patch fixed the bug in linux/6.16.0-rc4+
Perfect, thanks for the confirmation. It is not the correct value to
use, but I will now forward the report so we can gather input from
upstream on how it should be handled.
Regards,
Salvatore
Reply to: