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.
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to