[PATCH] ata: libata-core: Add NO_NCQ_TRIM quirk for Samsung PM893 (MZ7L3)

[PATCH] ata: libata-core: Add NO_NCQ_TRIM quirk for Samsung PM893 (MZ7L3)

[Tobias Kriebisch]

Samsung PM893 SATA SSDs (model prefix MZ7L3), the successor of the PM883
(MZ7LH), misbehave during trim on an AMD 600 Series chipset AHCI
controller (1022:43f6). The drives are three SAMSUNG MZ7L37T6HBLA-00A07
with firmware JXTC304Q, and the kernel reports "Features: Trust
NCQ-sndrcv" for them.

During a full-device trim, queued DSM TRIM commands are aborted:

  ata3.00: exception Emask 0x0 SAct 0x40e0740 SErr 0x0 action 0x0
  ata3.00: irq_stat 0x40000001
  ata3.00: failed command: SEND FPDMA QUEUED
  ata3.00: cmd 64/01:88:00:00:00/00:00:00:00:00/a0 tag 17 ncq dma 512 out
  ata3.00: status: { DRDY ERR }
  ata3.00: error: { ABRT }

In the same time windows, queued reads and writes time out and the link
is hard reset:

  ata2.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x6 frozen
  ata2.00: failed command: READ FPDMA QUEUED
  ata2.00: cmd 60/08:10:c0:82:f0/00:00:d4:02:00/40 tag 2 ncq dma 4096 in
  ata2.00: status: { DRDY }
  ata2: hard resetting link

Both kinds of errors occur on all three ports. In one case the system
hung and panicked shortly after the trim started.

Booting with libata.force=noncqtrim,nolpm makes the same full trim
complete without any ATA errors.

Add an entry for "SAMSUNG*MZ7L3*" with the same quirks as the existing
PM883 entry, which was added in commit ead089577e0f ("ata: libata-core:
Disable READ LOG DMA EXT for Samsung MZ7LH") for SEND FPDMA QUEUED
failures on AMD controllers.

Only ATA_QUIRK_NO_NCQ_TRIM and ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD (the
equivalent of noncqtrim and nolpm on this controller) were tested.
ATA_QUIRK_ZERO_AFTER_TRIM and ATA_QUIRK_NO_NCQ_ON_ATI mirror the PM883
entry. ATA_QUIRK_NO_NCQ_ON_ATI only applies to ATI (1002) controllers,
which were not available for testing.

Cc: stable@vger.kernel.org
Signed-off-by: Tobias Kriebisch <tobias.kriebisch@tecbeast.gmbh>
---

Notes:
    The patch itself was only build-tested (defconfig,
    drivers/ata/libata-core.o on top of for-7.4-fixes) and has not been
    booted. The runtime test was the equivalent
    libata.force=noncqtrim,nolpm on 6.18.60.
    
    Stable: ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD was introduced by commit
    e6bae5034ef4 ("ata: libata-core: Extend Samsung LPM quirk to AMD
    controllers") in v7.3-rc5, which is not tagged for stable. Older trees
    need that commit or an adjusted backport. With only
    ATA_QUIRK_NO_LPM_ON_ATI, LPM would stay enabled on AMD controllers such
    as this one.
    
    I used an AI coding assistant to draft the changelog from my notes and
    kernel logs, and to run checkpatch and the build test. The hardware
    testing and log data are mine, and I reviewed the patch.

 drivers/ata/libata-core.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5ff45a5cbfe4..a679988d5cd3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4443,6 +4443,10 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
 						ATA_QUIRK_ZERO_AFTER_TRIM |
 						ATA_QUIRK_NO_NCQ_ON_ATI |
 						ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD },
+	{ "SAMSUNG*MZ7L3*",		NULL,	ATA_QUIRK_NO_NCQ_TRIM |
+						ATA_QUIRK_ZERO_AFTER_TRIM |
+						ATA_QUIRK_NO_NCQ_ON_ATI |
+						ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD },
 	{ "FCCT*M500*",			NULL,	ATA_QUIRK_NO_NCQ_TRIM |
 						ATA_QUIRK_ZERO_AFTER_TRIM },
 

base-commit: a4845f077415ef32fe672c841e2fc58ae9e28273
-- 
2.56.0

Re: [PATCH] ata: libata-core: Add NO_NCQ_TRIM quirk for Samsung PM893 (MZ7L3)

[Niklas Cassel]

Hello Tobias,

On Mon, Nov 09, 2026 at 02:45:41PM +0100, Tobias Kriebisch wrote:
> Samsung PM893 SATA SSDs (model prefix MZ7L3), the successor of the PM883
> (MZ7LH), misbehave during trim on an AMD 600 Series chipset AHCI
> controller (1022:43f6). The drives are three SAMSUNG MZ7L37T6HBLA-00A07
> with firmware JXTC304Q, and the kernel reports "Features: Trust
> NCQ-sndrcv" for them.
> 
> During a full-device trim, queued DSM TRIM commands are aborted:
> 
>   ata3.00: exception Emask 0x0 SAct 0x40e0740 SErr 0x0 action 0x0
>   ata3.00: irq_stat 0x40000001
>   ata3.00: failed command: SEND FPDMA QUEUED
>   ata3.00: cmd 64/01:88:00:00:00/00:00:00:00:00/a0 tag 17 ncq dma 512 out
>   ata3.00: status: { DRDY ERR }
>   ata3.00: error: { ABRT }
> 
> In the same time windows, queued reads and writes time out and the link
> is hard reset:
> 
>   ata2.00: exception Emask 0x0 SAct 0x4 SErr 0x0 action 0x6 frozen
>   ata2.00: failed command: READ FPDMA QUEUED
>   ata2.00: cmd 60/08:10:c0:82:f0/00:00:d4:02:00/40 tag 2 ncq dma 4096 in
>   ata2.00: status: { DRDY }
>   ata2: hard resetting link
> 
> Both kinds of errors occur on all three ports. In one case the system
> hung and panicked shortly after the trim started.
> 
> Booting with libata.force=noncqtrim,nolpm makes the same full trim
> complete without any ATA errors.
> 
> Add an entry for "SAMSUNG*MZ7L3*" with the same quirks as the existing
> PM883 entry, which was added in commit ead089577e0f ("ata: libata-core:
> Disable READ LOG DMA EXT for Samsung MZ7LH") for SEND FPDMA QUEUED
> failures on AMD controllers.
> 
> Only ATA_QUIRK_NO_NCQ_TRIM and ATA_QUIRK_NO_LPM_ON_ATI_AND_AMD (the
> equivalent of noncqtrim and nolpm on this controller) were tested.
> ATA_QUIRK_ZERO_AFTER_TRIM and ATA_QUIRK_NO_NCQ_ON_ATI mirror the PM883
> entry. ATA_QUIRK_NO_NCQ_ON_ATI only applies to ATI (1002) controllers,
> which were not available for testing.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Tobias Kriebisch <tobias.kriebisch@tecbeast.gmbh>
> ---
> 
> Notes:
>     The patch itself was only build-tested (defconfig,
>     drivers/ata/libata-core.o on top of for-7.4-fixes) and has not been
>     booted. The runtime test was the equivalent
>     libata.force=noncqtrim,nolpm on 6.18.60.


6.18 was released a year ago.

Please boot the latest kernel, 7.4-rc2, and verify that the problem still
exists.

If the problem still exist on the latest kernel, apply the minimal set of
quirks needed to fix the problem.

And yes, build and boot a kernel with your patch to verify that the problem
is actually solved. (Don't take for granted that your patch will behave the
same as libata.force.)


Kind regards,
Niklas