On Thu, Apr 14, 2016 at 10:37 PM, Warren Block <wbl...@wonkity.com> wrote:
> On Thu, 14 Apr 2016, Warner Losh wrote: > > >> On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wbl...@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 _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"