| Message ID | 20190714224242.4689a874@natsu |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
| Series | libata: Disable queued TRIM for Samsung 860 series SSDs | expand |
Roman, > My Samsung 860 EVO mSATA 500GB SSD lockups for 20-30 seconds on > fstrim, while dmesg is repeatedly flooded with: Is that specific to the mSATA model? FWIW, queued TRIM works fine on the 2.5" form factor. So it would be best if we could limit the blacklist entry to the mSATA version (or a particular firmware rev).
On Mon, 15 Jul 2019 13:30:26 -0400 "Martin K. Petersen" <martin.petersen@oracle.com> wrote: > > Roman, > > > My Samsung 860 EVO mSATA 500GB SSD lockups for 20-30 seconds on > > fstrim, while dmesg is repeatedly flooded with: > > Is that specific to the mSATA model? > > FWIW, queued TRIM works fine on the 2.5" form factor. So it would be > best if we could limit the blacklist entry to the mSATA version (or a > particular firmware rev). Hello, I do not have other Samsung (m)SATA models to verify. On the bugreport someone confirmed this to be an issue for them too. Let's try asking if they have the mSATA model too, and what firmware revision. Mine is RVT42B6Q and there were no updates available last time I checked.
Roman, > I do not have other Samsung (m)SATA models to verify. On the bugreport > someone confirmed this to be an issue for them too. Let's try asking > if they have the mSATA model too, and what firmware revision. Mine is > RVT42B6Q and there were no updates available last time I checked. I have an mSATA drive arriving today. I'll see if I can come up with a suitable heuristic to distinguish between mSATA and the other form factors.
Roman, > I do not have other Samsung (m)SATA models to verify. On the bugreport > someone confirmed this to be an issue for them too. Let's try asking > if they have the mSATA model too, and what firmware revision. Mine is > RVT42B6Q and there were no updates available last time I checked. I have tested two mSATA 860s on two different systems, both with Intel AHCI controllers, and queued trim works fine for me. I'll try a few more things tomorrow.
On Thu, 18 Jul 2019 23:00:31 -0400 "Martin K. Petersen" <martin.petersen@oracle.com> wrote: > I have tested two mSATA 860s on two different systems, both with Intel > AHCI controllers, and queued trim works fine for me. What is the firmware version? Also, do you have an ASMedia ASM1062 controller to try (often seen on motherboards for additional SATA ports)? That's the one I tested with. Before tried with AMD chipset ones, but on those the 860s are known[1] to have serious NCQ issues in general, not just TRIM, so they are not useful for this test. With ASMedia only queued TRIM fails and everything else works fine. So I wonder if 850's queued TRIM issue in 860's case remains only on some SATA controllers. [1] https://bugzilla.kernel.org/show_bug.cgi?id=201693
Roman, > What is the firmware version? RVT41B6Q > Also, do you have an ASMedia ASM1062 controller to try (often seen on > motherboards for additional SATA ports)? That's the one I tested with. I'm afraid not. > With ASMedia only queued TRIM fails and everything else works fine. So I > wonder if 850's queued TRIM issue in 860's case remains only on some SATA > controllers. Looks likely. In that case we will have to extend the existing trim heuristic to match on controller as well.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index cbb162b683b6..1fe50b8fe00d 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4566,6 +4566,8 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, + { "Samsung SSD 860*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM, }, { "FCCT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, },
My Samsung 860 EVO mSATA 500GB SSD lockups for 20-30 seconds on fstrim, while dmesg is repeatedly flooded with: [ 332.792044] ata14.00: exception Emask 0x0 SAct 0x3fffe SErr 0x0 action 0x6 frozen [ 332.798271] ata14.00: failed command: SEND FPDMA QUEUED [ 332.804499] ata14.00: cmd 64/01:08:00:00:00/00:00:00:00:00/a0 tag 1 ncq dma 512 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [ 332.817145] ata14.00: status: { DRDY } Disabling queued TRIM for it, as already done for the 850 series models, solves the issue completely. Cc: Jens Axboe <axboe@kernel.dk> Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475 Signed-off-by: Roman Mamedov <rm@romanrm.net> --- drivers/ata/libata-core.c | 2 ++ 1 file changed, 2 insertions(+)