Date: Thu, 3 Nov 2022 16:12:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Daniel Engberg <diizzy@freebsd.org> Cc: Wojciech Puchar <wojtek@puchar.net>, freebsd-hackers@freebsd.org Subject: Re: SSD - trim fails Message-ID: <CANCZdfr7-50RYnUpZiv=EhN2B=_=h6O27RVEE_yigUiMwqUcFA@mail.gmail.com> In-Reply-To: <c035b8e407970b09e4ae6eb10d4a07eb@FreeBSD.org> References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> <CANCZdfrzu_mVFN=PHLrK9dHTb5ve7H=HN9bnRf9A1JHP4P4i3Q@mail.gmail.com> <c035b8e407970b09e4ae6eb10d4a07eb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000002340ac05ec9840db Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 4:09 PM Daniel Engberg <diizzy@freebsd.org> wrote: > 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 > Likely. I haven't checked Linux's block list for this yet. Warner --0000000000002340ac05ec9840db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 3, 2022 at 4:09 PM Daniel= Engberg <<a href=3D"mailto:diizzy@freebsd.org">diizzy@freebsd.org</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div s= tyle=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif"> <p id=3D"m_-2947172500766676165reply-intro">On 2022-11-03 23:02, Warner Los= h wrote:</p> <blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left:2px solid = rgb(16,16,255);margin:0px"> <div id=3D"m_-2947172500766676165replybody1"> <div dir=3D"ltr"> <div dir=3D"ltr">=C2=A0</div> <br> <div> <div dir=3D"ltr">On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar <<a href= =3D"mailto:wojtek@puchar.net" rel=3D"noreferrer" target=3D"_blank">wojtek@p= uchar.net</a>> wrote:</div> <blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">i have laptop with such SSD drive<br><br>ada0 a= t ahcich0 bus 0 scbus0 target 0 lun 0<br>ada0: <SAMSUNG SSD SM841N 2.5 7= mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x <br>device<br>ada0: Serial Number = S1K1NSAF415536<br>ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192byt= es)<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 t= rim<br><br>when trying trim - for 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>(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MA= NAGEMENT. 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): Re= trying command, 3 more tries remain<br>(ada0:ahcich0:0:0:0): SEND_FPDMA_QUE= UED DATA SET MANAGEMENT. ACB: 64 01 00 <br>00 00 40 00 00 00 00 00 00<br>(a= da0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error<br>(ada0:ahc= ich0:0:0:0): Retrying 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 err= or<br>(ada0:ahcich0:0:0:0): Retrying 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 r= emain<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:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MA= NAGEMENT. 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 i= s a problem?</blockquote> <div>=C2=A0</div> <div>The drive is reporting that it supports SDM. However, it's returni= ng a weird error code</div> <div>when fed the DSM we're sending it.</div> <div>=C2=A0</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>=C2=A0</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>=C2=A0</div> <div>Maybe it doesn't support queued DSM, despite all appearances to th= e contrary 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>=C2=A0</div> <div>There's a few other things it can be, but if it is only trim comma= nds that suffer from this, then</div> <div>they are quite unlikely.</div> <div>=C2=A0</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" tar= get=3D"_blank">https://bugzilla.kernel.org/show_bug.cgi?id=3D201693#c87</a>= </p></div></blockquote><div><br></div><div>Likely. I haven't checked Li= nux's block list for this yet.</div><div><br></div><div>Warner=C2=A0</d= iv></div></div> --0000000000002340ac05ec9840db--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfr7-50RYnUpZiv=EhN2B=_=h6O27RVEE_yigUiMwqUcFA>