From nobody Thu Nov  3 22:09:24 2022
X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
	by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3Hwq00VHz4gtZK
	for <freebsd-hackers@mlmmj.nyi.freebsd.org>; Thu,  3 Nov 2022 22:09:31 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4N3Hwn5KcPz3Ssj
	for <freebsd-hackers@freebsd.org>; Thu,  3 Nov 2022 22:09:29 +0000 (UTC)
	(envelope-from diizzy@FreeBSD.org)
Received: (Authenticated sender: daniel.engberg@pyret.net)
	by mail.gandi.net (Postfix) with ESMTPA id 812121C0006;
	Thu,  3 Nov 2022 22:09:24 +0000 (UTC)
List-Id: Technical discussions relating to FreeBSD <freebsd-hackers.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-hackers
List-Help: <mailto:freebsd-hackers+help@freebsd.org>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Subscribe: <mailto:freebsd-hackers+subscribe@freebsd.org>
List-Unsubscribe: <mailto:freebsd-hackers+unsubscribe@freebsd.org>
Sender: owner-freebsd-hackers@freebsd.org
MIME-Version: 1.0
Date: Thu, 03 Nov 2022 23:09:24 +0100
From: Daniel Engberg <diizzy@FreeBSD.org>
To: Warner Losh <imp@bsdimp.com>
Cc: Wojciech Puchar <wojtek@puchar.net>, freebsd-hackers@freebsd.org
Subject: Re: SSD - trim fails
In-Reply-To: <CANCZdfrzu_mVFN=PHLrK9dHTb5ve7H=HN9bnRf9A1JHP4P4i3Q@mail.gmail.com>
References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net>
 <CANCZdfrzu_mVFN=PHLrK9dHTb5ve7H=HN9bnRf9A1JHP4P4i3Q@mail.gmail.com>
Message-ID: <c035b8e407970b09e4ae6eb10d4a07eb@FreeBSD.org>
X-Sender: diizzy@FreeBSD.org
Content-Type: multipart/alternative;
 boundary="=_794d1166e47ca039a330a748619f286a"
X-Rspamd-Queue-Id: 4N3Hwn5KcPz3Ssj
X-Spamd-Bar: ---
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=none;
	spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::225 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::225:from];
	MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org];
	FROM_EQ_ENVFROM(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	R_DKIM_NA(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	R_SPF_SOFTFAIL(0.00)[~all];
	ARC_NA(0.00)[];
	FREEFALL_USER(0.00)[diizzy];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	TO_DN_SOME(0.00)[];
	RCPT_COUNT_THREE(0.00)[3];
	DMARC_NA(0.00)[freebsd.org];
	RCVD_TLS_LAST(0.00)[]
X-ThisMailContainsUnwantedMimeParts: N

--=_794d1166e47ca039a330a748619f286a
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



On 2022-11-03 23:02, Warner Losh wrote:

> On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar <wojtek@puchar.net> 
> wrote:
> 
>> i have laptop with such SSD drive
>> 
>> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
>> ada0: <SAMSUNG SSD SM841N 2.5 7mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x
>> device
>> ada0: Serial Number S1K1NSAF415536
>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
>> ada0: Command Queueing enabled
>> ada0: 244198MB (500118192 512 byte sectors)
>> 
>> everything works very good as long as i don't do trim
>> 
>> when trying trim - for example cleaning all drive with trim -f 
>> /dev/ada0
>> i'm getting
>> 
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
>> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 
>> 01 00
>> 00 00 40 00 00 00 00 00 00
>> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>> 
>> any ideas what is a problem?
> 
> The drive is reporting that it supports SDM. However, it's returning a 
> weird error code
> when fed the DSM we're sending it.
> 
> First, it could be a bug in how it does queued DSM requests. Normally 
> one can queue
> up a bunch of trim requests on newer drives. Perhaps this one gets 
> cranky.
> 
> Next, maybe the drive is lying the size of the DSM it will support, but 
> again, this is a weird
> message to report a request that's too long with.
> 
> Maybe it doesn't support queued DSM, despite all appearances to the 
> contrary from its
> identify tables. Try setting the trem method to DSM_TRIM:
> # sysctl kern.cam.ada.0.delete_method=DSM_TRIM
> should do the trick. At the very least, that will change the command we 
> send so if it can't
> handle that, then the error message will change. I suspect this may 
> clear up the problem.
> 
> There's a few other things it can be, but if it is only trim commands 
> that suffer from this, then
> they are quite unlikely.
> 
> Warner

There are a number of SSDs from Samsung that have TRIM disabled so maybe 
this also falls into that category?

https://bugzilla.kernel.org/show_bug.cgi?id=201693#c87

Best regards,

Daniel
--=_794d1166e47ca039a330a748619f286a
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p id=3D"reply-intro">On 2022-11-03 23:02, Warner Losh wrote:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div id=3D"replybody1">
<div dir=3D"ltr">
<div dir=3D"ltr">&nbsp;</div>
<br />
<div class=3D"v1gmail_quote">
<div class=3D"v1gmail_attr" dir=3D"ltr">On Wed, Nov 2, 2022 at 2:51 PM Wojc=
iech Puchar &lt;<a href=3D"mailto:wojtek@puchar.net" rel=3D"noreferrer">woj=
tek@puchar.net</a>&gt; wrote:</div>
<blockquote class=3D"v1gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid #cccccc; padding-left: 1ex;">i have laptop with such SS=
D drive<br /><br />ada0 at ahcich0 bus 0 scbus0 target 0 lun 0<br />ada0: &=
lt;SAMSUNG SSD SM841N 2.5 7mm 256GB DXM03D0Q&gt; ACS-2 ATA SATA 3.x <br />d=
evice<br />ada0: Serial Number S1K1NSAF415536<br />ada0: 600.000MB/s transf=
ers (SATA 3.x, UDMA6, PIO 8192bytes)<br />ada0: Command Queueing enabled<br=
 />ada0: 244198MB (500118192 512 byte sectors)<br /><br /><br />everything =
works very good as long as i don't do trim<br /><br />when trying trim - fo=
r example cleaning all drive with trim -f /dev/ada0 <br />i'm getting<br />=
<br />(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain<br />(ada=
0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 <br =
/>00 00 40 00 00 00 00 00 00<br />(ada0:ahcich0:0:0:0): CAM status: Uncorre=
ctable parity/CRC error<br />(ada0:ahcich0:0:0:0): Retrying command, 3 more=
 tries remain<br />(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEM=
ENT. ACB: 64 01 00 <br />00 00 40 00 00 00 00 00 00<br />(ada0:ahcich0:0:0:=
0): CAM status: Uncorrectable parity/CRC error<br />(ada0:ahcich0:0:0:0): R=
etrying command, 3 more tries remain<br />(ada0:ahcich0:0:0:0): SEND_FPDMA_=
QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 <br />00 00 40 00 00 00 00 00 00<=
br />(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error<br />=
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain<br />(ada0:ahci=
ch0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 <br />00 0=
0 40 00 00 00 00 00 00<br />(ada0:ahcich0:0:0:0): CAM status: Uncorrectable=
 parity/CRC error<br />(ada0:ahcich0:0:0:0): Retrying command, 3 more tries=
 remain<br />(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. A=
CB: 64 01 00 <br />00 00 40 00 00 00 00 00 00<br />(ada0:ahcich0:0:0:0): CA=
M status: Uncorrectable parity/CRC error<br />(ada0:ahcich0:0:0:0): Retryin=
g command, 3 more tries remain<br />(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED=
 DATA SET MANAGEMENT. ACB: 64 01 00 <br />00 00 40 00 00 00 00 00 00<br />(=
ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error<br /><br />=
<br />any ideas what is a problem?</blockquote>
<div>&nbsp;</div>
<div>The drive is reporting that it supports SDM. However, it's returning a=
 weird error code</div>
<div>when fed the DSM we're sending it.</div>
<div>&nbsp;</div>
<div>First, it could be a bug in how it does queued DSM requests. Normally =
one can queue</div>
<div>up a bunch of trim requests on newer drives. Perhaps this one gets cra=
nky.</div>
<div>&nbsp;</div>
<div>Next, maybe the drive is lying the size of the DSM it will support, bu=
t again, this is a weird</div>
<div>message to report a request that's too long with.</div>
<div>&nbsp;</div>
<div>Maybe it doesn't support queued DSM, despite all appearances to the co=
ntrary from its</div>
<div>identify tables. Try setting the trem method to DSM_TRIM:</div>
<div># sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM</div>
<div>should do the trick. At the very least, that will change the command w=
e send so if it can't</div>
<div>handle that, then the error message will change. I suspect this may cl=
ear up the problem.</div>
<div>&nbsp;</div>
<div>There's a few other things it can be, but if it is only trim commands =
that suffer from this, then</div>
<div>they are quite unlikely.</div>
<div>&nbsp;</div>
<div>Warner</div>
</div>
</div>
</div>
</blockquote>
<p>There are a number of SSDs from Samsung that have TRIM disabled so maybe=
 this also falls into that category?</p>
<p><a href=3D"https://bugzilla.kernel.org/show_bug.cgi?id=3D201693#c87">htt=
ps://bugzilla.kernel.org/show_bug.cgi?id=3D201693#c87</a></p>
<p>Best regards,</p>
<p>Daniel</p>
<p><br /></p>

</body></html>

--=_794d1166e47ca039a330a748619f286a--