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

[Niklas Cassel <cassel@kernel.org>]

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