From nobody Thu Nov 03 22:12:07 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 4N3J060wBhz4gtKG for ; Thu, 3 Nov 2022 22:12:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3J052NDfz3V3D for ; Thu, 3 Nov 2022 22:12:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id a13so5215492edj.0 for ; Thu, 03 Nov 2022 15:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s/j9r/E6UEVnyJs6/vHz8/E+zD/XOHlhHbFn5tSeTYk=; b=cDgti50/Tiqs2TOAFa/cAA5OcwODehgCQV3kKMIrf/L/Zzh0X4A808n8pcWcfCT5ky d3IMJG2qJOn+HCWkCj+65/iLpLTHSAdBx4BR3+qirnPOnNsJ1FcAiYsbsSI2IuXoKeRx xbe3yuhcC/W3ftl+WTHmAO3/37OKpLDyE0r6gSYhVMbq0vkaO7Vi/X8YdlEJXtxiRw/8 N/IZTI6velPoy0KF+IbkfJOrY6P3AqP1H/apGajUWiceFfyfJMQKZ/A/fbZVfDPBkZOO JT5abhBs9FYL6nhWkOTy4VvQSoUqo8toV6O0k/9NjgcU/KHqJcUOi70BiU4bTEDkCgCt Oufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s/j9r/E6UEVnyJs6/vHz8/E+zD/XOHlhHbFn5tSeTYk=; b=eWHE7jqvuqjVMDW1cy3yqLYvPgfSZyMj24emnIc0+46J8FkwtziXCcQSByw3OMAJlQ SX6lC0uC0A5jYyTpPoewwduzwiPf8XH/vD1yIEiSJumeBIg3HVIa9DZP3oi321ZCDrM6 vjy93+JhNzVgtf6kbMsdd3Lz4F3qMTD/werfDVNWoJM9TUfozradk2t3djef6a7Ry9t5 vee5aCzOlMoAuo4OIrvA0VvBBcLEHnbKS8AQksRJ4gnpHLP7Es+gIy0npf4J2IOAIJrW 7v+UgUuMyR0IWhs1//0jxOa1Z2APibwQgfDXXD7s1rgSn5GD4Bf3oMtlmLQQQ+IzckM+ IXGQ== X-Gm-Message-State: ACrzQf1X95AoBobbgn2vdVtnVjccMra2ivzeNZYisifq/UYAnAt20JUW B1XlMS/GTMjq8HD+KsYKqxSq3+lpAS88fO7b46/0jw== X-Google-Smtp-Source: AMsMyM4lDM/930RauEgiwLJrVIOBdAhS99tLwL8P2HckmUFBe98GcvZjAnACsm2/klaaBSsSYsgmlhuP5/KV2KPpaXU= X-Received: by 2002:aa7:c859:0:b0:463:4b54:16a8 with SMTP id g25-20020aa7c859000000b004634b5416a8mr25488487edt.136.1667513538783; Thu, 03 Nov 2022 15:12:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 16:12:07 -0600 Message-ID: Subject: Re: SSD - trim fails To: Daniel Engberg Cc: Wojciech Puchar , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002340ac05ec9840db" X-Rspamd-Queue-Id: 4N3J052NDfz3V3D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="cDgti50/"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000002340ac05ec9840db Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 4:09 PM Daniel Engberg wrote: > On 2022-11-03 23:02, Warner Losh wrote: > > > > On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar wrote: > > i have laptop with such SSD drive > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: 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


=
On Thu, Nov 3, 2022 at 4:09 PM Daniel= Engberg <diizzy@freebsd.org&g= t; wrote:

On 2022-11-03 23:02, Warner Los= h wrote:

=C2=A0

On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar <wojtek@p= uchar.net> wrote:
i have laptop with such SSD drive

ada0 a= t ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <SAMSUNG SSD SM841N 2.5 7= mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x
device
ada0: Serial Number = S1K1NSAF415536
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192byt= es)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte= sectors)


everything works very good as long as i don't do t= rim

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 MA= NAGEMENT. 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): Re= trying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUE= UED DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(a= da0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahc= ich0: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 err= or
(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 r= emain
(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 MA= NAGEMENT. 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 i= s a problem?
=C2=A0
The drive is reporting that it supports SDM. However, it's returni= ng a weird error code
when fed the DSM we're sending it.
=C2=A0
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 cra= nky.
=C2=A0
Next, maybe the drive is lying the size of the DSM it will support, bu= t again, this is a weird
message to report a request that's too long with.
=C2=A0
Maybe it doesn't support queued DSM, despite all appearances to th= e contrary from its
identify tables. Try setting the trem method to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM
should do the trick. At the very least, that will change the command w= e send so if it can't
handle that, then the error message will change. I suspect this may cl= ear up the problem.
=C2=A0
There's a few other things it can be, but if it is only trim comma= nds that suffer from this, then
they are quite unlikely.
=C2=A0
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=3D201693#c87=


Likely. I haven't checked Li= nux's block list for this yet.

Warner=C2=A0
--0000000000002340ac05ec9840db--