Re: Heads up

On Thu, Apr 14, 2016 at 10:37 PM, Warren Block <wblock_at_wonkity.com> wrote:

> On Thu, 14 Apr 2016, Warner Losh wrote:
>
>
>> On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wblock_at_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