Date: Thu, 14 Apr 2016 22:37:40 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Heads up Message-ID: <alpine.BSF.2.20.1604142225390.8359@wonkity.com> In-Reply-To: <CANCZdfqEWDLrHndKf8ZND1mM7spK9cq%2BnfnA79EVEaSj-MJfFA@mail.gmail.com> References: <CANCZdfpnYnVrvhNagYUT9RhAuC1AMCrxh=GCt8RKT0bqxuJybw@mail.gmail.com> <alpine.BSF.2.20.1604142154240.8359@wonkity.com> <CANCZdfqEWDLrHndKf8ZND1mM7spK9cq%2BnfnA79EVEaSj-MJfFA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Apr 2016, Warner Losh wrote: > > On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wblock@wonkity.com> wrote: > On Thu, 14 Apr 2016, Warner Losh wrote: > > The CAM I/O scheduler has been committed to current. This work is described > in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > default scheduler doesn't change the default (old) behavior. > > One possible issue, however, is that it also enables NCQ Trims on ada SSDs. > There are a few rogue drives that claim support for this feature, but > actually implement data corrupt instead of queued trims. The list of known > rogues is believed to be complete, but some caution is in order. > > > Is the list of drives queryable? Is there an easy way to tell if the currently-connected drives are on the list? > > > /usr/src/sys/cam/ata/ata_da.c has the list. > > dmesg will tell you if it detected a bad one since it prints the drive's quirks. > But that's no big deal, because the bad one work just fine if you never issue > a NCQ TRIM. This small group of drives were early adapters of this technology > > Here's the full list of known rogues: > > Crucial/Micron M500 (all firmware prior to MU07) > Micron M510 MU01 firmware (newer firmware is good) > Crucial/Micron M550 MU01 firmware (newer firmware is good) > Crucial MX100 MU01 firmware (newer firmware is good) > FCCT M500 all firmware > Samsung 830 all firmware > Samsung 840 all firmware > Samsung 850 all firmware > > All of these are at least 18 months old (if not older). There's some confusing in Linux lists on > the full impact of the Samsung drives (there was a bug in the Linux implementation (that can't > be present in the FreeBSD implementation) that may have been the root cause for the Samsung > black listing). Out of an abundance of caution, I've kept them in the list. Also, it's my belief that > the Crucial/Micron models with MU01 firmware were mostly corrected after early samples > since most of the channel drives I've helped people debug had MU02 firmware. Also, a quick > google search shows the MU02 firmware for each of these models has been available for > at least a year. After updating a Dell E7240, booting showed a bunch of FPDMA errors and then panicked after about 30 seconds. The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q. I believe this is the OEM version of the Samsung 840 Evo. According to the Dell support page, the machine shipped on January 22, 2015. So while the drive might not have been manufactured in a while, Dell was still using them that recently. Note that this is a used machine, I have only had it a week. After booting with mfsBSD, a quick fsck, and setting kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without errors and appears to be working normally. From owner-freebsd-current@freebsd.org Fri Apr 15 04:45:27 2016 Return-Path: <owner-freebsd-current@freebsd.org> Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79A96AECE01 for <freebsd-current@mailman.ysv.freebsd.org>; Fri, 15 Apr 2016 04:45:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 344D51011 for <freebsd-current@freebsd.org>; Fri, 15 Apr 2016 04:45:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x230.google.com with SMTP id f1so10904587igr.1 for <freebsd-current@freebsd.org>; Thu, 14 Apr 2016 21:45:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=KCbytk6JesJtT1ltQyuIuwRW8Aib84Gku25ktMis5wA=; b=vvV3DDtnMGMJpyijWzRM9Zeac+7IwDNYNjJUCfc0uME/m22eBS2LItxYv5WO2DdgO6 HKo78GtZl6sPJJi3sBxqXhbnWmykW7adHSCftqlXTJRqg6GJCRShP7K6+59WxX7VeS1v maXYYQSMXlI+G1xBidHXZVf5yvzvVRjvLxrSPYaEkQR6NlIViMp5OjzmnnXoyMTxupBa uAzx2XOO334PqEuDmuk4fp/k93B5ByPbBKPeZtGM9ErRAop20292OTSwOw7RKT365eOx 9ECiK/fBtfxGoZp33FypaDZvo/+epfPl4rWNyr7/caBj2s/RTONs1iacLnGBWmLgkqOr XELw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KCbytk6JesJtT1ltQyuIuwRW8Aib84Gku25ktMis5wA=; b=Sz3BvTJGprcK099xUSQYbY0s4IsZlf2dr974f1jnD2BnsHlprsE4w5RcCaRYYng7PH TmojuT4uRbdasqHKHyZyGbS2xlF7WXBrhX45O8yRfs+lH+/+Wk9j0KuLdhEc+8slpwFq 71+8KIEYXm1AFc+lOSLU7E0KlVN20734RIDbL4dkpnUUclwLrlr6ePKtaB8Dzg2b9hcQ UweZAO0WLNChA8wyRSZQwgtTiUJv0dW/7XSnp0XiMBtPhZSyiU9Hc+Sa8W0Bo/yyrPxJ tgpNFLDMvdSdqu5s+OdGV120bRenIAJSPpon/KbT/MCvPPTizpq1yPS0OH9ZvdB8EHdA 3V6A== X-Gm-Message-State: AOPr4FXQMR7osJZAp7SapUjDriBvYv/mf8WbXDlddw6bKTM+cjo53ILHpGfiyQDQ/FSf8UmkCW/op99M6U+lTg== MIME-Version: 1.0 X-Received: by 10.50.67.113 with SMTP id m17mr2331925igt.52.1460695526547; Thu, 14 Apr 2016 21:45:26 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Thu, 14 Apr 2016 21:45:26 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <alpine.BSF.2.20.1604142225390.8359@wonkity.com> References: <CANCZdfpnYnVrvhNagYUT9RhAuC1AMCrxh=GCt8RKT0bqxuJybw@mail.gmail.com> <alpine.BSF.2.20.1604142154240.8359@wonkity.com> <CANCZdfqEWDLrHndKf8ZND1mM7spK9cq+nfnA79EVEaSj-MJfFA@mail.gmail.com> <alpine.BSF.2.20.1604142225390.8359@wonkity.com> Date: Thu, 14 Apr 2016 22:45:26 -0600 X-Google-Sender-Auth: 0X1DNC4TVuI7UjCJubLqZUiTEz4 Message-ID: <CANCZdfoYFRt=PhezS-sF96VCyCNAehcCbRc_Fzi1i8TvC-rZGw@mail.gmail.com> Subject: Re: Heads up From: Warner Losh <imp@bsdimp.com> To: Warren Block <wblock@wonkity.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2016 04:45:27 -0000 On Thu, Apr 14, 2016 at 10:37 PM, Warren Block <wblock@wonkity.com> wrote: > On Thu, 14 Apr 2016, Warner Losh wrote: > > >> On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wblock@wonkity.com> wrote: >> On Thu, 14 Apr 2016, Warner Losh wrote: >> >> The CAM I/O scheduler has been committed to current. This >> work is described >> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf >> though the >> default scheduler doesn't change the default (old) behavior. >> >> One possible issue, however, is that it also enables NCQ >> Trims on ada SSDs. >> There are a few rogue drives that claim support for this >> feature, but >> actually implement data corrupt instead of queued trims. The >> list of known >> rogues is believed to be complete, but some caution is in >> order. >> >> >> Is the list of drives queryable? Is there an easy way to tell if >> the currently-connected drives are on the list? >> >> >> /usr/src/sys/cam/ata/ata_da.c has the list. >> >> dmesg will tell you if it detected a bad one since it prints the drive's >> quirks. >> But that's no big deal, because the bad one work just fine if you never >> issue >> a NCQ TRIM. This small group of drives were early adapters of this >> technology >> >> Here's the full list of known rogues: >> >> Crucial/Micron M500 (all firmware prior to MU07) >> Micron M510 MU01 firmware (newer firmware is good) >> Crucial/Micron M550 MU01 firmware (newer firmware is good) >> Crucial MX100 MU01 firmware (newer firmware is good) >> FCCT M500 all firmware >> Samsung 830 all firmware >> Samsung 840 all firmware >> Samsung 850 all firmware >> >> All of these are at least 18 months old (if not older). There's some >> confusing in Linux lists on >> the full impact of the Samsung drives (there was a bug in the Linux >> implementation (that can't >> be present in the FreeBSD implementation) that may have been the root >> cause for the Samsung >> black listing). Out of an abundance of caution, I've kept them in the >> list. Also, it's my belief that >> the Crucial/Micron models with MU01 firmware were mostly corrected after >> early samples >> since most of the channel drives I've helped people debug had MU02 >> firmware. Also, a quick >> google search shows the MU02 firmware for each of these models has been >> available for >> at least a year. >> > > After updating a Dell E7240, booting showed a bunch of FPDMA errors and > then panicked after about 30 seconds. > > The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q. I believe > this is the OEM version of the Samsung 840 Evo. According to the Dell > support page, the machine shipped on January 22, 2015. So while the drive > might not have been manufactured in a while, Dell was still using them that > recently. Note that this is a used machine, I have only had it a week. > > After booting with mfsBSD, a quick fsck, and setting > kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without errors > and appears to be working normally. What does "camcontrol identify" say for this drive? Sounds like a good candidate for a quirk... Thanks for testing. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1604142225390.8359>