Skip site navigation (1)Skip section navigation (2)
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
Message-ID:  <c035b8e407970b09e4ae6eb10d4a07eb@FreeBSD.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
--=_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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c035b8e407970b09e4ae6eb10d4a07eb>