From nobody Thu Nov 3 22:02:54 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 4N3HnS2jJmz4gsQ5 for ; Thu, 3 Nov 2022 22:03:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 4N3HnR1dCTz3Rgx for ; Thu, 3 Nov 2022 22:03:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x630.google.com with SMTP id k2so8941469ejr.2 for ; Thu, 03 Nov 2022 15:03:07 -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=YwiRIh55ZlDuxZ5N1/YRebK6E0ryuoi9Xig5LMwYUkk=; b=Vfn4TGU4djRsSKg4qhoObqsvjSPOz7b3BEYNuG1c5/A8kG+8TbFCzlSMW03Eq+fZj/ 5O5siKtTBOjBibQH84nG9a14wl40a4bfFr47fISPp5kbNimOUu3feaLvPeIjqBaeGF4z +XHhbhRLEph0VimfHNGqOqUGN3PQG/7umCO8bzOPOaqPJg3bVik3VxNWdMzstzQpq+Oz L350SkFM7Br50zwyhOe548sB06yysWDMW5oZTtaPGtH+d+SoiVdIt2tOBQ5UhJqRqhB2 eyoy94lM7cppfs7ezHvryDHh9/on7NLSsrCOA3heSMK5AbBP+S3S56txB27zwFsWN1kv MTBg== 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=YwiRIh55ZlDuxZ5N1/YRebK6E0ryuoi9Xig5LMwYUkk=; b=UKvzUCOhkSd512TNmV9D3BNTosVBqopmtadUZfENoO2fEEFAkuRq7jQS3qxodUf5nJ d7PdiQgOPlg/3piSgQjuYK5gZeVutNRuad/+ssLnbETBgbfe9svdNK81zbKp/s8qLd8G JKLawN/z7Bp5pT/aDRCwf6IPQztbuaOEG1agn9PmOBcnbwF54mLH7zWWcgyzXA8Ckwkk jVDUyvjmIFeZoei8sZYNGxGuOu+UCvTl3/OB4BnBlgsRBoMOZRYH/2kPdcEsZC+IpZFb WZmMZgk7t2pgdIxaHe8FsWdjUjjv72KyLTD0/tOwWwk0xWV7EiUNN+zxyj9VrnMABgXi 77xg== X-Gm-Message-State: ACrzQf21NNJ9yYTIiDxRoSLQ216uGYkd860zSYFIfWizPyGe5DMLvA/C VhZnKrWmsCC3U+0unN2M55xCx4dKAdD4JQatswdh0WqEBL4= X-Google-Smtp-Source: AMsMyM6HCHyLzifwrSTItMkpEVRhXSUY/6WYVrbHMMoiyV3rN3zfeu3TL8w0UxvM4DeQoEfXHHwiyjoZN28FEjtVT2E= X-Received: by 2002:a17:906:3b17:b0:7ad:b645:9e3e with SMTP id g23-20020a1709063b1700b007adb6459e3emr28094032ejf.140.1667512985491; Thu, 03 Nov 2022 15:03:05 -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: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> From: Warner Losh Date: Thu, 3 Nov 2022 16:02:54 -0600 Message-ID: Subject: Re: SSD - trim fails To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000028b2f605ec981fe1" X-Rspamd-Queue-Id: 4N3HnR1dCTz3Rgx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Vfn4TGU4; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::630) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --00000000000028b2f605ec981fe1 Content-Type: text/plain; charset="UTF-8" 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 --00000000000028b2f605ec981fe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 2, 2022 at 2:51 PM Wojcie= ch 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 erro= r 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. Perha= ps 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 t= o the contrary from its
identify tables. Try setting the trem met= hod to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM=
should do the trick. At the very least, that will change the com= mand we send so if it can't
handle that, then the error messa= ge 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 com= mands that suffer from this, then
they are quite unlikely.
<= div>
Warner
--00000000000028b2f605ec981fe1--