Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD 916a

Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD 916a

[Niklas Cassel]

On Mon, Oct 26, 2026 at 03:30:00PM +0100, Thierry Vignaud wrote:
> On Mon, Oct 26, 2026 at 3:09 PM Thierry Vignaud <tvignaud@redhat.com> wrote:
> 
> > Hi
> > This fixes https://bugzilla.kernel.org/show_bug.cgi?id=220693
> > Basically my SSD was having issues with NCQ since I got it last year.
> > I workarounded it by disabling NCQ for a year but it turns out that
> > disabling LPM fixes it w/o the huge performance hit.
> > I've seen other reports in some forums so let's fix it for all.
> > Please consider it for backporting to stable releases too.
> > Thanks
> >
> 
> I saw you submitted the 7.4 initial MR
> Is there any chance the above patch could make it into 7.4 ?

Yes, I expect Damien will queue it up and send it for 7.4-rc2.

However, your patch appears to be corrupted (it fails to apply
with git am), so I think you need to send a V2.

Make sure you generate it with git format-patch and send it out
with git send-email.


Kind regards,
Niklas

Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD 916a

[Niklas Cassel]

Hello Thierry,

On Mon, Oct 26, 2026 at 04:55:07PM +0100, Thierry Vignaud wrote:
> That's strange because I did use "git format-patch -1"
> I reran it, it's exactly the same file.
> However I generated on top of Linus' tree.
> Here's the same applied on top of "for-7.4"

I don't think the problem is how you generated the patch (git format-patch).
It seems to be how you sent it out.
(It appears that you did not use git send-email.)

As you can see, the mailing list rejected your email:
https://lore.kernel.org/linux-ide/at9wk18uhg-H18ge@ryzen/T/#u

Most likely because:
Content-Type: multipart/mixed;

instead of:
Content-Type: text/plain;

git send-email should send it out as plain-text.

I can see that you are sending using gmail, see:
https://git-scm.com/docs/git-send-email#_use_gmail_as_the_smtp_server

For how to configure git send-email with gmail.


> 
> This patch survived heavy I/O such as compiling a kernel multiple times.
> However I hit the NCQ issue after trying suspending (which I remember was
> an issue too).
> On resume, I hit
> I've attached dmesg to https://bugzilla.kernel.org/show_bug.cgi?id=222187
> See https://bugzilla.kernel.org/attachment.cgi?id=311297
> 
> Note the following (one hour before suspending?):
> [12014.334779] sd 0:0:0:0: [sda] tag#25 timing out command, waited 7s
> [12612.911419] sd 0:0:0:0: [sda] tag#16 timing out command, waited 7s
> 
> Then when suspending/resuming:
> 
> [16199.520287] PM: suspend entry (deep)
> [16199.525373] Filesystems sync: 0.005 seconds
> [16199.532331] Freezing user space processes
> [16199.533685] Freezing user space processes completed (elapsed 0.001
> seconds)
> [16199.533689] OOM killer disabled.
> [16199.533690] Freezing remaining freezable tasks
> [16199.534837] Freezing remaining freezable tasks completed (elapsed 0.001
> seconds)
> [16199.534881] printk: Suspending console(s) (use no_console_suspend to
> debug)
> [16199.553767] e1000e: EEE TX LPI TIMER: 00000011
> [16199.578187] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
> [16199.578249] serial 00:02: disabled
> [16199.578307] sd 4:0:0:0: [sdc] Synchronizing SCSI cache
> [16199.578315] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [16199.579852] ata1.00: Entering standby power mode
> …
> Resuming:
> [16200.017987] PM: suspend exit
> [16200.101972] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [16200.101995] ata6: SATA link down (SStatus 4 SControl 300)
> [16200.102060] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [16200.102076] ata3: SATA link down (SStatus 4 SControl 300)
> [16200.102590] sd 0:0:0:0: [sda] Starting disk
> [16200.103016] ata1.00: configured for UDMA/133
> [16200.118929] ata2.00: configured for UDMA/100
> [16200.240742] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04:
> bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
> [16203.543281] e1000e 0000:00:1f.6 eno2: NIC Link is Up 1000 Mbps Full
> Duplex, Flow Control: Rx/Tx
> [16205.102517] ata4: link is slow to respond, please be patient (ready=0)
> [16205.103508] ata5: link is slow to respond, please be patient (ready=0)
> [16215.160283] ata5: link is slow to respond, please be patient (ready=0)
> [16215.160305] ata4: link is slow to respond, please be patient (ready=0)
> [16217.967230] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [16218.011741] sd 4:0:0:0: [sdc] Starting disk
> [16218.045035] ata5.00: configured for UDMA/133
> [16218.274151] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [16218.310512] sd 3:0:0:0: [sdb] Starting disk
> [16218.343817] ata4.00: configured for UDMA/133
> [16306.847985] ata1.00: exception Emask 0x0 SAct 0x7fc00000 SErr 0x0 action
> 0x6 frozen
> [16306.848009] ata1.00: failed command: WRITE FPDMA QUEUED
> [16306.848015] ata1.00: cmd 61/40:b0:18:70:44/05:00:39:00:00/40 tag 22 ncq
> dma 688128 out
>                         res 40/00:01:00:00:00/00:00:00:00:00/40 Emask 0x4
> (timeout)
> [16306.848034] ata1.00: status: { DRDY }
> 
> ata1 being the SSD:
> [    0.654757] ata1.00: ATA-11: PNY 1TB SATA SSD, H220916a, max UDMA/133
> 
> Any idea what I could try  (besides disabling suspending)?

I'm guessing it is a drive firmware bug.

Have you checked if there is any more recent firmware version for your SSD?


Kind regards,
Niklas

Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD 916a

[Thierry Vignaud]

On Mon, Oct 26, 2026 at 5:41 PM Niklas Cassel <cassel@kernel.org> wrote:
>
> > This patch survived heavy I/O such as compiling a kernel multiple times.
> > However I hit the NCQ issue after trying suspending (which I remember was
> > an issue too).
> > On resume, I hit
> > I've attached dmesg to https://bugzilla.kernel.org/show_bug.cgi?id=222187
> > See https://bugzilla.kernel.org/attachment.cgi?id=311297
> >
> > Note the following (one hour before suspending?):
> > [12014.334779] sd 0:0:0:0: [sda] tag#25 timing out command, waited 7s
> > [12612.911419] sd 0:0:0:0: [sda] tag#16 timing out command, waited 7s
> >
> > Then when suspending/resuming:
> >
> > [16199.520287] PM: suspend entry (deep)
> > [16199.525373] Filesystems sync: 0.005 seconds
> > [16199.532331] Freezing user space processes
> > [16199.533685] Freezing user space processes completed (elapsed 0.001
> > seconds)
> > [16199.533689] OOM killer disabled.
> > [16199.533690] Freezing remaining freezable tasks
> > [16199.534837] Freezing remaining freezable tasks completed (elapsed 0.001
> > seconds)
> > [16199.534881] printk: Suspending console(s) (use no_console_suspend to
> > debug)
> > [16199.553767] e1000e: EEE TX LPI TIMER: 00000011
> > [16199.578187] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
> > [16199.578249] serial 00:02: disabled
> > [16199.578307] sd 4:0:0:0: [sdc] Synchronizing SCSI cache
> > [16199.578315] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > [16199.579852] ata1.00: Entering standby power mode
> > …
> > Resuming:
> > [16200.017987] PM: suspend exit
> > [16200.101972] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [16200.101995] ata6: SATA link down (SStatus 4 SControl 300)
> > [16200.102060] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [16200.102076] ata3: SATA link down (SStatus 4 SControl 300)
> > [16200.102590] sd 0:0:0:0: [sda] Starting disk
> > [16200.103016] ata1.00: configured for UDMA/133
> > [16200.118929] ata2.00: configured for UDMA/100
> > [16200.240742] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04:
> > bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
> > [16203.543281] e1000e 0000:00:1f.6 eno2: NIC Link is Up 1000 Mbps Full
> > Duplex, Flow Control: Rx/Tx
> > [16205.102517] ata4: link is slow to respond, please be patient (ready=0)
> > [16205.103508] ata5: link is slow to respond, please be patient (ready=0)
> > [16215.160283] ata5: link is slow to respond, please be patient (ready=0)
> > [16215.160305] ata4: link is slow to respond, please be patient (ready=0)
> > [16217.967230] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [16218.011741] sd 4:0:0:0: [sdc] Starting disk
> > [16218.045035] ata5.00: configured for UDMA/133
> > [16218.274151] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > [16218.310512] sd 3:0:0:0: [sdb] Starting disk
> > [16218.343817] ata4.00: configured for UDMA/133
> > [16306.847985] ata1.00: exception Emask 0x0 SAct 0x7fc00000 SErr 0x0 action
> > 0x6 frozen
> > [16306.848009] ata1.00: failed command: WRITE FPDMA QUEUED
> > [16306.848015] ata1.00: cmd 61/40:b0:18:70:44/05:00:39:00:00/40 tag 22 ncq
> > dma 688128 out
> >                         res 40/00:01:00:00:00/00:00:00:00:00/40 Emask 0x4
> > (timeout)
> > [16306.848034] ata1.00: status: { DRDY }
> >
> > ata1 being the SSD:
> > [    0.654757] ata1.00: ATA-11: PNY 1TB SATA SSD, H220916a, max UDMA/133
> >
> > Any idea what I could try  (besides disabling suspending)?
>
> I'm guessing it is a drive firmware bug.
>
> Have you checked if there is any more recent firmware version for your SSD?

Sadly this vendor doesn't appear to offer any firmware update.

Re: [PATCH] ata: libata-core: Add NOLPM quirk for PNY 1TB SATA SSD 916a

[Thierry Vignaud]

On Mon, Oct 26, 2026 at 8:06 PM Thierry Vignaud <tvignaud@redhat.com> wrote:
>
> On Mon, Oct 26, 2026 at 5:41 PM Niklas Cassel <cassel@kernel.org> wrote:
> >
> > > This patch survived heavy I/O such as compiling a kernel multiple times.
> > > However I hit the NCQ issue after trying suspending (which I remember was
> > > an issue too).
> > > On resume, I hit
> > > I've attached dmesg to https://bugzilla.kernel.org/show_bug.cgi?id=222187
> > > See https://bugzilla.kernel.org/attachment.cgi?id=311297
> > >
> > > Note the following (one hour before suspending?):
> > > [12014.334779] sd 0:0:0:0: [sda] tag#25 timing out command, waited 7s
> > > [12612.911419] sd 0:0:0:0: [sda] tag#16 timing out command, waited 7s
> > >
> > > Then when suspending/resuming:
> > >
> > > [16199.520287] PM: suspend entry (deep)
> > > [16199.525373] Filesystems sync: 0.005 seconds
> > > [16199.532331] Freezing user space processes
> > > [16199.533685] Freezing user space processes completed (elapsed 0.001
> > > seconds)
> > > [16199.533689] OOM killer disabled.
> > > [16199.533690] Freezing remaining freezable tasks
> > > [16199.534837] Freezing remaining freezable tasks completed (elapsed 0.001
> > > seconds)
> > > [16199.534881] printk: Suspending console(s) (use no_console_suspend to
> > > debug)
> > > [16199.553767] e1000e: EEE TX LPI TIMER: 00000011
> > > [16199.578187] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
> > > [16199.578249] serial 00:02: disabled
> > > [16199.578307] sd 4:0:0:0: [sdc] Synchronizing SCSI cache
> > > [16199.578315] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > [16199.579852] ata1.00: Entering standby power mode
> > > …
> > > Resuming:
> > > [16200.017987] PM: suspend exit
> > > [16200.101972] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > > [16200.101995] ata6: SATA link down (SStatus 4 SControl 300)
> > > [16200.102060] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > > [16200.102076] ata3: SATA link down (SStatus 4 SControl 300)
> > > [16200.102590] sd 0:0:0:0: [sda] Starting disk
> > > [16200.103016] ata1.00: configured for UDMA/133
> > > [16200.118929] ata2.00: configured for UDMA/100
> > > [16200.240742] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04:
> > > bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
> > > [16203.543281] e1000e 0000:00:1f.6 eno2: NIC Link is Up 1000 Mbps Full
> > > Duplex, Flow Control: Rx/Tx
> > > [16205.102517] ata4: link is slow to respond, please be patient (ready=0)
> > > [16205.103508] ata5: link is slow to respond, please be patient (ready=0)
> > > [16215.160283] ata5: link is slow to respond, please be patient (ready=0)
> > > [16215.160305] ata4: link is slow to respond, please be patient (ready=0)
> > > [16217.967230] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > > [16218.011741] sd 4:0:0:0: [sdc] Starting disk
> > > [16218.045035] ata5.00: configured for UDMA/133
> > > [16218.274151] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> > > [16218.310512] sd 3:0:0:0: [sdb] Starting disk
> > > [16218.343817] ata4.00: configured for UDMA/133
> > > [16306.847985] ata1.00: exception Emask 0x0 SAct 0x7fc00000 SErr 0x0 action
> > > 0x6 frozen
> > > [16306.848009] ata1.00: failed command: WRITE FPDMA QUEUED
> > > [16306.848015] ata1.00: cmd 61/40:b0:18:70:44/05:00:39:00:00/40 tag 22 ncq
> > > dma 688128 out
> > >                         res 40/00:01:00:00:00/00:00:00:00:00/40 Emask 0x4
> > > (timeout)
> > > [16306.848034] ata1.00: status: { DRDY }
> > >
> > > ata1 being the SSD:
> > > [    0.654757] ata1.00: ATA-11: PNY 1TB SATA SSD, H220916a, max UDMA/133
> > >
> > > Any idea what I could try  (besides disabling suspending)?
> >
> > I'm guessing it is a drive firmware bug.
> >
> > Have you checked if there is any more recent firmware version for your SSD?
>
> Sadly this vendor doesn't appear to offer any firmware update.

I've send another version of the patch, using git send-email this time.
Sadly, I'd to add NONCQ and reduce the speed else I was still able to
reproduce the issue.
At least SSD is functionnal, though with reduced performances.