Date: Thu, 3 Nov 2022 16:02:54 -0600 From: Warner Losh <imp@bsdimp.com> To: Wojciech Puchar <wojtek@puchar.net> Cc: freebsd-hackers@freebsd.org Subject: Re: SSD - trim fails Message-ID: <CANCZdfrzu_mVFN=PHLrK9dHTb5ve7H=HN9bnRf9A1JHP4P4i3Q@mail.gmail.com> In-Reply-To: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000028b2f605ec981fe1 Content-Type: text/plain; charset="UTF-8" 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 --00000000000028b2f605ec981fe1 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 Wed, Nov 2, 2022 at 2:51 PM Wojcie= ch Puchar <<a href=3D"mailto:wojtek@puchar.net">wojtek@puchar.net</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" 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 at ahcich0 bus 0 scbus0 target 0 lun 0<br> ada0: <SAMSUNG SSD SM841N 2.5 7mm 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 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 - for example cleaning all drive with trim -f /dev/ada0 <b= r> 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 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 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 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 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 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 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?<br></blockquote><div><br></div><div>The drive = is reporting that it supports SDM. However, it's returning a weird erro= r code</div><div>when fed the DSM we're sending it.</div><div><br></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. Perha= ps this one gets cranky.</div><div><br></div><div>Next, maybe the drive is = lying the size of the DSM it will support, but again, this is a weird</div>= <div>message to report a request that's too long with.</div><div><br></= div><div>Maybe it doesn't support queued DSM, despite all appearances t= o the contrary from its</div><div>identify tables. Try setting the trem met= hod 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 com= mand we send so if it can't</div><div>handle that, then the error messa= ge will change. I suspect this may clear up the problem.</div><div><br></di= v><div>There's a few other things it can be, but if it is only trim com= mands that suffer from this, then</div><div>they are quite unlikely.</div><= div><br></div><div>Warner<br></div></div></div> --00000000000028b2f605ec981fe1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrzu_mVFN=PHLrK9dHTb5ve7H=HN9bnRf9A1JHP4P4i3Q>