Samsung SSD 840 failed to get NCQ Send/Recv Log Emask 0x1 failed to set xfermode (err_mask=0x40) on upstream kernels >= 3.12

I would like to point out that it was working properly with previous Ubuntu releases.
I tweaked BIOS settings testing AHCI mode and SATA mode without success.

One more question, maybe It's a bit off-topic, I just tested unofficial kernel taken from here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14.11-utopic/

I installed and booted version 3.14.11-031411-generic_3.14.11-031411.201407062254_amd64
and noticed a different message during boot:

ata4.00: failed to set xfermode (err_mask=0x40)

This change was made by a bot.

Augusto Bortoluzzi, could you please test the latest upstream kernel available from the very top line at the top of the page (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.16-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Thanks Christopher, I tested with 3 kernels and 2 upstream.

The error changed from Trusty 3.13.0-30-generic to upstream kernels:

from: failed to get NCQ Send/Recv Log Emask 0x1 > failed to set xfermode (err_mask=0x40)

Maybe I need to edit the subject?

Augusto Bortoluzzi, could you please advise to what actual impact this would have on your ability to use your computer?

Dear Christopher, It is a blocking issue since I had to buy another HDD in order to install ubuntu 14.04

Thanks Christopher, in the meanwhile I reinstalled Ubuntu 13.10 and tested a few kernel versions.
The problem appeared upstream starting from kernel version 3.12.x onward.
So I reinstalled again 14.04 and I downgraded to kernel version v3.11.10.13-saucy, which is not affected by this bug-

I reported the problem to linux-kernel ML: https://lkml.org/lkml/2014/7/16/724

This really scared the hell out of me. My first SDD and now it's going to die I thought. Thanks for pointing out it was a bug. Tested on Ubuntu 14.04.1 32/64. On both cases it shows the error many times. Some days it repeats the error endlessly.

Please could you confirm this bug to official LKML https://lkml.org/lkml/2014/7/16/724
so maybe someone could notice it or could address it to the right person. Thanks

When I use dmesg I see the following lines:

allard@ubuntu-laptop-allard:~$ dmesg | grep ata1
[ 1.196018] ata1: SATA max UDMA/133 abar m2048@0xc2617000 port 0xc2617100 irq 42
[ 1.515247] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 1.515449] ata1.00: supports DRM functions and may not be fully accessible
[ 1.515545] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 1.515547] ata1.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0BB6Q, max UDMA/133
[ 1.515549] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[ 1.515782] ata1.00: supports DRM functions and may not be fully accessible
[ 1.515851] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 1.515854] ata1.00: configured for UDMA/133

Can anyone tell me what "failed to get NCQ Send/Recv Log Emask 0x1" exactly means?

I am also getting these errors with mint17

I am getting the same error. I have tried as well a Live USB of Ubuntu 14.10 Beta, which fails to detect the drive (I can't risk installing the whole system as this is my "production" computer).

I have tried with a 3.17 kernel and still got the same error.

Dear Sirs,
I have the same drive model, Mint 17 gives me the same error, so does Windows 7, well not exactly the same error but it is not able to sync at sata 3 speeds and goes down to sata 1 ( same happens in linux ) would this be the same issue?

Augusto Bortoluzzi, could you please test 3.18-rc3 and advise to the results?

If reproducible, the next step is to fully commit bisect from kernel 3.12 to 3.13 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ? Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

I have solved the problem with an update to the Firmware.
I have followed the instructions at this page (as Samsung tools only works from Windows/DOS):
https://www.content-space.de/dokuwiki/blog/2012/updating_a_samsung_ssd_840_firmware_with_linux

I am happily running a 3.13 kernel version:
Linux Maggie 3.13.0-40-generic #69-Ubuntu SMP Thu Nov 13 17:53:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The updated firmware does not solve this for me, the message is still there: 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ata1.00: failed to get NCQ Send/Recv Log Emask 0x1

see https://bugzilla.kernel.org/show_bug.cgi?id=72341

tilo kremer, thank you for your comment. So your problem and hardware may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into the default Ubuntu kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
https://wiki.ubuntu.com/Kernel/Policies/DuplicateBugs
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

As well, please do not announce in this report you created a new bug report.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

This has been reported on the Kernel Bug Tracker;

https://bugzilla.kernel.org/show_bug.cgi?id=72341

According to them queued trim support is broke on the drive.

I also experienced this on an 840 Pro and now I have the same issue on an 850 Pro.

It's my understanding we have to wait on a fix from Samsung, so maybe someone at Canonical knows how to get a hold of Samsung to let them know that queued trim support is broken on their SSDs in Linux...

Does anyone have any contact information the end-user can contact Samsung over this matter, and I don't mean <email address hidden> that email address is pointless...

The queued trim support is broke on the SSD's from Samsung and the fix is going to have to come from them, but I'm wondering if they're even aware of this since it's been going on for a few years now.

I think it's best if end-users can contact Samsung, so they are aware, but we need some good contact info, if anyone knows?

During a fresh install today (14.04.1 on Samsung 850 Pro) I also hit this bug.
I noticed the same issue on a 13.04 install on a Samsung 840 Pro (after fw upgrade) that I am running for quite some time now.
Allthough running fstrim manually is still working, I found this litte test which seems to work and confirm TRIM is active and working.
I thought I'd register and share this (hopefully) useful info with you.
Run test as per description below:

http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2/

Hope this shed some light on the matter....

It would really be great if Canonical, or the developers could contact Samsung, if anyone knows how?

I wonder if Samsung is even aware of this situation, or if they really care. I'd hate to think we're going to have to sit around and wait on this, because this has been going in their SSDs already over a year, what's to say this is ever going to get fixed, unless we get some Developmental Clout out there sending them word?

PLEASE Canonical I IMPLORE you KINDLY to reach out to Samsung over this?

It would also be great if someone can reply to this post here and let us know too?

THANK YOU! :)

By the way, for testing Trim support, just get this script below, and run it, it's a lot simpler to use, instead of all the reading and doing from the link binjarac (coppensmeister) provided...

wget -O /tmp/test_trim.sh "https://sites.google.com/site/lightrush/random-1/checkiftrimonext4isenabledandworking/test_trim.sh?attredirects=0&d=1"

You can also read about it here;

http://lightrush.ndoytchev.com/random-1/checkiftrimonext4isenabledandworking

I have the same on Ubuntu 14.04 and 3.17.8

Mar 12 20:36:21 icanseeyou kernel: [ 2.344273] scsi host1: ahci
Mar 12 20:36:21 icanseeyou kernel: [ 2.344352] scsi host2: ahci
Mar 12 20:36:21 icanseeyou kernel: [ 2.344443] scsi host3: ahci
Mar 12 20:36:21 icanseeyou kernel: [ 2.344532] scsi host4: ahci
Mar 12 20:36:21 icanseeyou kernel: [ 2.345871] scsi host5: ahci
Mar 12 20:36:21 icanseeyou kernel: [ 2.345927] ata1: DUMMY
Mar 12 20:36:21 icanseeyou kernel: [ 2.345927] ata2: DUMMY
Mar 12 20:36:21 icanseeyou kernel: [ 2.345929] ata3: SATA max UDMA/133 abar m2048@0xf7f15000 port 0xf7f15200 irq 31
Mar 12 20:36:21 icanseeyou kernel: [ 2.345929] ata4: DUMMY
Mar 12 20:36:21 icanseeyou kernel: [ 2.345931] ata5: SATA max UDMA/133 abar m2048@0xf7f15000 port 0xf7f15300 irq 31
Mar 12 20:36:21 icanseeyou kernel: [ 2.345931] ata6: DUMMY
Mar 12 20:36:21 icanseeyou kernel: [ 2.457966] usb 3-11: new high-speed USB device number 2 using xhci_hcd
Mar 12 20:36:21 icanseeyou kernel: [ 2.920255] Switched to clocksource tsc
Mar 12 20:36:21 icanseeyou kernel: [ 2.989771] usb 3-11: New USB device found, idVendor=0424, idProduct=2514
Mar 12 20:36:21 icanseeyou kernel: [ 2.989772] usb 3-11: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar 12 20:36:21 icanseeyou kernel: [ 2.990144] hub 3-11:1.0: USB hub found
Mar 12 20:36:21 icanseeyou kernel: [ 2.990196] hub 3-11:1.0: 4 ports detected
Mar 12 20:36:21 icanseeyou kernel: [ 3.025645] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 12 20:36:21 icanseeyou kernel: [ 3.025657] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 12 20:36:21 icanseeyou kernel: [ 3.026877] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded
Mar 12 20:36:21 icanseeyou kernel: [ 3.026879] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out
Mar 12 20:36:21 icanseeyou kernel: [ 3.026879] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out
Mar 12 20:36:21 icanseeyou kernel: [ 3.027612] ata3.00: failed to get NCQ Send/Recv Log Emask 0x1
Mar 12 20:36:21 icanseeyou kernel: [ 3.027612] ata3.00: ATA-9: Samsung SSD 840 EVO 250GB, EXT0BB0Q, max UDMA/133
Mar 12 20:36:21 icanseeyou kernel: [ 3.027613] ata3.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Mar 12 20:36:21 icanseeyou kernel: [ 3.027828] ata3.00: failed to get NCQ Send/Recv Log Emask 0x1
Mar 12 20:36:21 icanseeyou kernel: [ 3.027829] ata3.00: configured for UDMA/133

I'm on Ubuntu 12.04 with kernel 3.13.0-49-generic and experiencing the same problem with a freshly bought Samsung SSD 850 Pro and can confirm what already has been stated at https://bugzilla.kernel.org/show_bug.cgi?id=72341.

- Enabled NCQ and TRIM (=queued TRIM) causes errors and a fallback after some timeout to SATA with 3Gb/s
- Setting either libata.force=noncq or disabling TRIM via mount options resolves the issue

My dmesg looks slighty different, though. I will post it later.

I am running the EXT0DB6Q firmware on my 840 EVO + 3.13.0-53 , and think this issue may have cleared up somewhat.

The first time I ran
chiluk@beastly:/etc/cron.weekly$ sudo fstrim /home
I got.
^[OQfstrim: /home: FITRIM ioctl failed: Input/output error

The Log showed
[164782.716062] ata2.00: exception Emask 0x0 SAct 0x1000004 SErr 0x0 action 0x6 frozen
[164782.716079] ata2.00: failed command: WRITE FPDMA QUEUED
[164782.716081] ata2.00: cmd 61/60:10:28:b6:c0/00:00:1e:00:00/40 tag 2 ncq 49152 out
[164782.716081] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[164782.716083] ata2.00: status: { DRDY }
[164782.716084] ata2.00: failed command: WRITE FPDMA QUEUED
[164782.716086] ata2.00: cmd 61/08:c0:00:1b:ce/00:00:30:00:00/40 tag 24 ncq 4096 out
[164782.716086] res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[164782.716087] ata2.00: status: { DRDY }
[164782.716090] ata2: hard resetting link
[164783.036088] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[164783.036268] ata2.00: supports DRM functions and may not be fully accessible
[164783.036537] ata2.00: supports DRM functions and may not be fully accessible
[164783.036584] ata2.00: configured for UDMA/133
[164783.052085] ata2.00: device reported invalid CHS sector 0
[164783.052093] ata2: EH complete

It sounds like the drive was just taking too long for the writes to complete. Hence the (timeout). I ran it a second time, and did not get these errors. These errors may also be related to the charge degredation of the the TLC nand on these drives. This may be also partially due to the way the samsung firmware is managing sectors on the drive. In that it might be needing to restructure/rewrite metadata due to my recent firmware update.

I then went and cleaned some 30gb out of my home dir, and ran it a third time. I did not get any errors this time.

Also how are you guys "enabling trim". It is recommended that you not enable trim by adding discard to the mount options. This will greatly slow down deletes. Instead it is recommended that you let fstrim-all run out of anacron /etc/cron.weekly/fstrim. Your above trim tests will show that trim is not enabled, when it is actually being run weekly in the background. If you need trim run more frequently than that move it to the daily or hourly folder. Just be careful with doing so.

I'm running 3.13.0-53-generic from ubuntu, with the latest EXT0DB6Q, on a q87 motherboard connected to sata 3 connectors, and am not seeing the original issue.

[ 1.108155] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
<snip>
[ 1.110025] ata2.00: supports DRM functions and may not be fully accessible
[ 1.110107] ata2.00: ATA-9: Samsung SSD 840 EVO 500GB, EXT0DB6Q, max UDMA/133
[ 1.110110] ata2.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[ 1.110293] ata2.00: supports DRM functions and may not be fully accessible
[ 1.110336] ata2.00: configured for UDMA/133

Is anyone seeing this issue that has the drive connected sata 3 (6gbps) ports? I wonder if the drive is doing something different when connected to sata 2.

So after some additional testing it looks like NCQ Trim on the Samsung 8** drives still has "issues".

It looks like it mostly works, but once the drive gets saturated with a large trim *(i.e. deleting 5 kernel trees, and then fstrimming), the kernel starts to hit timeouts. Increasing the timeouts to 200 seconds or more appears to alleviate these errors, but upstream has already blacklisted the drive altogether for NCQ trim.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9a9324d396967

I've integrated the 9a9324d396967 NO NCQ Trim fix into this ppa.

https://launchpad.net/~chiluk/+archive/ubuntu/samsungncqtrim

Please test it and report back here either way. I'll remove the ppa when the fix hits the kernels in -updates.

Status changed to 'Confirmed' because the bug affects multiple users.

Does the last kernel update (kernel 3.19.0-20.20) contain the fix?

I saw no reference to any Samsung SSD, at its changelog.

http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/log/?h=master-next

Seems this one has been commited after the -20 build :(

@loannis,

That is correct it will be in the -21 build of the vivid kernel, . We have 3 week kernel integration and test cycles. There will be an automated message posted here when the kernel that contains the fix is pushed to the -proposed archives.

It should be noted that most of the Ubuntu Kernel devs that have an 840 EVO are already running the EXT0DB6Q firmware without serious issue. The only minor issues are timeouts related to ncq trim taking too long in certain cases. The kernel fix removes ncq-trim which consequently removes those messages as well.

I should say that whenever upgrading firmware on a drive please make sure you have recent backups of your data, especially considering the nature of this issue.

It's very possible that the electron leakage in the NAND may have already corrupted your data, and the new firmware may not be able to restore the infrequently used/rewritten sectors *(not confirmed, but given my understanding of the problem this is a plausible explanation for some of the issues others are seeing). That being said the new firmware is supposed to help avoid this situation in the future, and as suck I whole-heartedly recommend the upgrade. Not only does it fix this issue, but performance is again restored.

If you have not disabled NCQ in /etc/default/grub, if you run

fstrim -av

manually 3-4 times, one after the other, you will get data loss.

It has happened to me with *buntus 14.04.2, 14.10, 15.04.

If you disable NCQ in grub, everything is fine.

The command is

fstrim-all

in *buntus 14.04.

Also, for data loss to occur, you must have something like 60-70 GB of data on the filesystem.

Data loss does not occur, if you have just clean installed some *buntu.

@loannis, How do you know you have data loss, and how do you know that Ubuntu/Linux is the reason for that data loss?

None of the error message I've seen posted to the cases related to Samsung SSDs imply that linux is causing data loss when running trim.

The fix is in kernel 4.0.5 and I can confirm it fixes the problem. Been running the latest firmware on my EVO 840 SSD for a few days now and everything looks good.

I have reached out to Samsung again to hopefully get this falsely advertised feature fixed at the firmware level, since the firmware is at fault for advertising FPDMA QUEUED support (which is what QUEUED TRIM uses), even though it doesn't support it at all.

Read this post for the letter I sent to Samsung:
https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005/comments/55

You can also check prior comments by me and others in that thread, to see more information.

@gimpsmart your e-mail is well written, but I don't believe it applies to the EXT0DB6Q for the 840 EVO.

We no longer receive the "failed to get NCQ Send/Recv Log Emask 0x1" errors with this level of firmware which implies that the log has been correctly implemented. Samsung may simply need to re-spin the firmware for your 850 Pro drive with the fix.

That being said, running a large fstrim on a EXT0DB6Q drive did still show timeout similar to below
"
[164782.716079] ata2.00: failed command: WRITE FPDMA QUEUED
[164782.716081] ata2.00: cmd 61/60:10:28:b6:c0/00:00:1e:00:00/40 tag 2 ncq 49152 out
[164782.716081] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
"

It is because of these timeout errors that we decided to pull the upstream commit to disable NCQ trim on samsung SSDs.

Are there any users of the EXT0DB6Q firmware that are still get the "failed to get NCQ Send/Recv Log Emask 0x1" errors?

@chiluk: yes, i did before adding libata.force=noncq to my kernel command line.

another article on SSDs from this manufacturer has further information: https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Samsung SSD 850 Pro, EXM02B6Q, Trusty with 3.13.0-55. There is no errors in dmesg, multiple fstrim operatins runs just fine. Strange.

Through, script in OP doesn't work correctly.
fstrim: ./: FITRIM ioctl failed: input/output error

There are problems with the 850 Pro as well, see, e.g.:

http://ubuntuforums.org/showthread.php?t=2282808&p=13305283

This bug was fixed in the package linux - 3.19.0-22.22

---------------
linux (3.19.0-22.22) vivid; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1465755

  [ Tai Nguyen ]

  * SAUCE: power: reset: Add syscon reboot device node for APM X-Gene
    platform
    - LP: #1463211

  [ Upstream Kernel Changes ]

  * Revert "dm crypt: fix deadlock when async crypto algorithm returns
    -EBUSY"
    - LP: #1465696
  * Bluetooth: ath3k: Add a new ID 0cf3:e006 to ath3k list
    - LP: #1459934
  * cdc-acm: prevent infinite loop when parsing CDC headers.
    - LP: #1460657
  * (upstream) libata: Blacklist queued TRIM on all Samsung 800-series
    - LP: #1338706, #1449005
  * powerpc/powernv: Check image loaded or not before calling flash
    - LP: #1461553
  * ahci: avoton port-disable reset-quirk
    - LP: #1458617
  * Bluetooth: btusb: support public address configuration for ath3012
    - LP: #1459937
  * Bluetooth: btusb: Add setup callback for chip init on USB
    - LP: #1459937
  * Bluetooth: btusb: Add support for QCA ROME chipset family
    - LP: #1459937
  * Bluetooth: btusb: Fix incorrect type in qca_device_info
    - LP: #1459937
  * Bluetooth: btusb: Fix minor whitespace issue in QCA ROME device entries
    - LP: #1459937
  * Bluetooth: btusb: Add support for 0cf3:e007
    - LP: #1459937
  * storvsc: Set the SRB flags correctly when no data transfer is needed
    - LP: #1439780
  * vfs: read file_handle only once in handle_to_path
    - LP: #1416503
    - CVE-2015-1420
  * ozwpan: Use unsigned ints to prevent heap overflow
    - LP: #1463442
    - CVE-2015-4001
  * ozwpan: divide-by-zero leading to panic
    - LP: #1463445
    - CVE-2015-4003
  * ozwpan: Use proper check to prevent heap overflow
    - LP: #1463444
    - CVE-2015-4002
  * ozwpan: unchecked signed subtraction leads to DoS
    - LP: #1463444
    - CVE-2015-4002
  * enclosure: fix WARN_ON removing an adapter in multi-path devices
    - LP: #1415178
  * ASoC: tfa9879: Fix return value check in tfa9879_i2c_probe()
    - LP: #1465696
  * ASoC: samsung: s3c24xx-i2s: Fix return value check in
    s3c24xx_iis_dev_probe()
    - LP: #1465696
  * ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
    - LP: #1465696
  * ASoC: rt5677: add register patch for PLL
    - LP: #1465696
  * btrfs: unlock i_mutex after attempting to delete subvolume during send
    - LP: #1465696
  * ALSA: hda - Fix mute-LED fixed mode
    - LP: #1465696
  * ALSA: hda - Add mute-LED mode control to Thinkpad
    - LP: #1465696
  * arm64: dma-mapping: always clear allocated buffers
    - LP: #1465696
  * ALSA: emu10k1: Fix card shortname string buffer overflow
    - LP: #1465696
  * ALSA: emux: Fix mutex deadlock at unloading
    - LP: #1465696
  * drm/radeon: Use drm_calloc_ab for CS relocs
    - LP: #1465696
  * drm/radeon: adjust pll when audio is not enabled
    - LP: #1465696
  * drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
    - LP: #1465696
  * drm/radeon: fix lockup when BOs aren't part of the VM on release
    - LP: #1465696
  * drm/radeon: reset BOs address after clearing it.
    - LP: #1465696
  * drm/radeon: check new address before removing old one
  ...

Does someone know which kernel version introduced the "queued trim"? My 3.2 kernel seems to be not affected by this problem.

Hi All
First of all thanks for your job!

I have an SSD 840 EVO firmware DXT06B0Q (NOT yet update cause this problem!!)

I'm using linux MINT 17.1 64bit with Kernel 3.13.0-37

Have I to upgrado to kernel 3.19 or will be available an official Kernel update for the 3.13.** default on Mint 17.1 OR Will be updated the Mint 17.2 official with kernel 3.16.***??

Many thanks in advance!

@Cyberbob, I'm in the same situation:

SSD 840 EVO and Linux Mint 17.1 Mate Edition...

*If you upgrade your 840 firmware you will need to **rebuild a custom*
*kernel with the proper ATA HORKAGE, as I do since the upgrade,*
*or you will need to use libata.force=noncq (**which I discourage)**.*

*Don't know if and when the patch will be included in stock kernel,*
*bot the lates (3.13.0-37-generic) stil have this problem..**.*

*Hope for Mint 17.2 "Rafaela"...*

On Sun, Jun 21, 2015 at 10:47 AM, Cyberbob <email address hidden> wrote:

> Hi All
> First of all thanks for your job!
>
> I have an SSD 840 EVO firmware DXT06B0Q (NOT yet update cause this
> problem!!)
>
> I'm using linux MINT 17.1 64bit with Kernel 3.13.0-37
>
> Have I to upgrado to kernel 3.19 or will be available an official Kernel
> update for the 3.13.** default on Mint 17.1 OR Will be updated the Mint
> 17.2 official with kernel 3.16.***??
>
> Many thanks in advance!
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1449005).
> https://bugs.launchpad.net/bugs/1338706
>
> Title:
> Samsung SSD 840 failed to get NCQ Send/Recv Log Emask 0x1 failed to
> set xfermode (err_mask=0x40) on upstream kernels >= 3.12
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706/+subscriptions
>

@Cyberbob, I'm in the same situation:

SSD 840 EVO and Linux Mint 17.1 Mate Edition...

If you upgrade your 840 firmware you will need to rebuild a custom
kernel with the proper ATA HORKAGE, as I do since the upgrade,
or you will need to use libata.force=noncq (which I discourage).

Don't know if and when the patch will be included in stock kernel,
but the latest (3.13.0-37-generic) still have this problem...

Hope for Mint 17.2 "Rafaela"...

You can modify single ata channels too like I do, it works fine:

/etc/default/grub
GRUB_CMDLINE_LINUX="libata.force=10:noncq,9:noncq"

@Cyberbob, there is a fix coming for *buntus 14.04 (Trusty), as you can see at the beginning of this page ("Fix Committed").

When the message becomes "Fix Released", the updated kernel will be avaible to all *buntus 14.04.

I do not remember if Linux Mint uses the official Ubuntu repositories.

If it does, when the message becomes "Fix Released", the updated kernel will be available to Linux Mint.

Since Linux Mint doesn't show all updates available via its graphical update program, you will have to install them, by running in terminal:

sudo apt-get update

and then

sudo apt-get dist-upgrade

In the meantime instead of modifying your boot command line you could test the 3.13 ppa that contains the fix that will eventually make it into the updated kernel.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706/comments/34

I've updated to the latest kernel via Vivid Proposed (linux-image-extra-3.19.0-22-generic 3.19.0-22.22) which per commit log should fix the error, but I still see it:

$ dmesg | grep ata
[ 0.000000] BIOS-e820: [mem 0x00000000c8f9e000-0x00000000c8ffffff] ACPI data
[ 0.000000] ACPI: SSDT 0x00000000C8FE6258 0003D2 (v01 SataRe SataTabl 00001000 INTL 20120711)
[ 0.000000] Memory: 8056616K/8291736K available (8001K kernel code, 1232K rwdata, 3752K rodata, 1408K init, 1300K bss, 235120K reserved, 0K cma-reserved)
[ 0.233271] ACPI : EC: GPE = 0x10, I/O: command/status = 0x934, data = 0x930
[ 0.233500] libata version 3.00 loaded.
[ 0.573463] Write protecting the kernel read-only data: 12288k
[ 0.613795] ata1: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a100 irq 28
[ 0.613798] ata2: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a180 irq 28
[ 0.613800] ata3: SATA max UDMA/133 abar m2048@0xf7d3a000 port 0xf7d3a200 irq 28
[ 0.613801] ata4: DUMMY
[ 0.613802] ata5: DUMMY
[ 0.932913] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 0.933919] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 0.933922] ata1.00: ATA-9: Samsung SSD 840 Series, DXT09B0Q, max UDMA/133
[ 0.933924] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 0.934365] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 0.934369] ata1.00: configured for UDMA/133
[ 0.934578] ata1.00: Enabling discard_zeroes_data
[ 0.934724] ata1.00: Enabling discard_zeroes_data
[ 0.935481] ata1.00: Enabling discard_zeroes_data
[ 1.252796] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1.255611] ata2.00: ATAPI: HL-DT-ST DVD+/-RW GU90N, A100, max UDMA/100
[ 1.260480] ata2.00: configured for UDMA/100
[ 1.604669] ata3: SATA link down (SStatus 0 SControl 300)
[ 1.630033] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 1.848143] systemd[1]: Starting Increase datagram queue length...
[ 1.858239] systemd[1]: Started Increase datagram queue length.
[ 3.471525] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

I'm on an old Samsung SSD840 (first series) (not EVO or PRO)

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-utopic' to 'verification-done-utopic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

mmmm....

"If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed."

I really do not understand those sentences... what tag should be used if I've verified that the kernel in proposed
does *not* solve the problem ? Because not setting 'verification-done-vivid' will result in the bug to be dropped... which obviosly I don't want do happen.
If instead someone sets 'verification-needed-vivid' (as already happened) this will imply that the bug is solved, but it is not (at least for me).
Instruction unclear. Core dumped :-)

So, I already use the proposed (3.19.0-22-generic) kernel on Vivid Vervet, I installed it days ago. The discard mount option and the fstrim command are works now, without any problem. Please do not drop the path, but move this kernel to the stable repository.

@munbi, have you installed the latest firmware available for your SSD?

You can find it here:

http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/downloads.html

Trusty LTS Vivid Kernel 3.19.0-22.22 works for me too for a Samsung SSD 840 Pro.

Trusty LTS Kernel 3.13.0-57 works for me too for a Samsung SSD 840 Pro.

@IoannisVranos, thanks for the link, but I'm already on the latest firmware version for this drive (DXT09B0Q).
Maybe this drive simply does not support getting NCQ Log Emask...

[ 1.439428] ata1.00: failed to get NCQ Send/Recv Log Emask 0x1

Hi All,
In my Linux Mint 17.1
if I do:
sudo smartctl -a /dev/sda | grep SATA\ Version
I receive:
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)

I don't understand if this means that I'M NOT affected to this Bug.

Can I do :
fstrim -v / >> $LOG

without risk??

You need to check you firmware version:

> sudo hdparm -i /dev/sda | grep FwRev
Model=Samsung SSD 840 EVO 250GB, FwRev=EXT0DB6Q, SerialNo=xxxxx

If you have the latest rev EXT0DB6Q, then you need the fixed kernel mentioned above.

This bug was fixed in the package linux - 3.19.0-22.22

---------------
linux (3.19.0-22.22) vivid; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1465755

  [ Tai Nguyen ]

  * SAUCE: power: reset: Add syscon reboot device node for APM X-Gene
    platform
    - LP: #1463211

  [ Upstream Kernel Changes ]

  * Revert "dm crypt: fix deadlock when async crypto algorithm returns
    -EBUSY"
    - LP: #1465696
  * Bluetooth: ath3k: Add a new ID 0cf3:e006 to ath3k list
    - LP: #1459934
  * cdc-acm: prevent infinite loop when parsing CDC headers.
    - LP: #1460657
  * (upstream) libata: Blacklist queued TRIM on all Samsung 800-series
    - LP: #1338706, #1449005
  * powerpc/powernv: Check image loaded or not before calling flash
    - LP: #1461553
  * ahci: avoton port-disable reset-quirk
    - LP: #1458617
  * Bluetooth: btusb: support public address configuration for ath3012
    - LP: #1459937
  * Bluetooth: btusb: Add setup callback for chip init on USB
    - LP: #1459937
  * Bluetooth: btusb: Add support for QCA ROME chipset family
    - LP: #1459937
  * Bluetooth: btusb: Fix incorrect type in qca_device_info
    - LP: #1459937
  * Bluetooth: btusb: Fix minor whitespace issue in QCA ROME device entries
    - LP: #1459937
  * Bluetooth: btusb: Add support for 0cf3:e007
    - LP: #1459937
  * storvsc: Set the SRB flags correctly when no data transfer is needed
    - LP: #1439780
  * vfs: read file_handle only once in handle_to_path
    - LP: #1416503
    - CVE-2015-1420
  * ozwpan: Use unsigned ints to prevent heap overflow
    - LP: #1463442
    - CVE-2015-4001
  * ozwpan: divide-by-zero leading to panic
    - LP: #1463445
    - CVE-2015-4003
  * ozwpan: Use proper check to prevent heap overflow
    - LP: #1463444
    - CVE-2015-4002
  * ozwpan: unchecked signed subtraction leads to DoS
    - LP: #1463444
    - CVE-2015-4002
  * enclosure: fix WARN_ON removing an adapter in multi-path devices
    - LP: #1415178
  * ASoC: tfa9879: Fix return value check in tfa9879_i2c_probe()
    - LP: #1465696
  * ASoC: samsung: s3c24xx-i2s: Fix return value check in
    s3c24xx_iis_dev_probe()
    - LP: #1465696
  * ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
    - LP: #1465696
  * ASoC: rt5677: add register patch for PLL
    - LP: #1465696
  * btrfs: unlock i_mutex after attempting to delete subvolume during send
    - LP: #1465696
  * ALSA: hda - Fix mute-LED fixed mode
    - LP: #1465696
  * ALSA: hda - Add mute-LED mode control to Thinkpad
    - LP: #1465696
  * arm64: dma-mapping: always clear allocated buffers
    - LP: #1465696
  * ALSA: emu10k1: Fix card shortname string buffer overflow
    - LP: #1465696
  * ALSA: emux: Fix mutex deadlock at unloading
    - LP: #1465696
  * drm/radeon: Use drm_calloc_ab for CS relocs
    - LP: #1465696
  * drm/radeon: adjust pll when audio is not enabled
    - LP: #1465696
  * drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
    - LP: #1465696
  * drm/radeon: fix lockup when BOs aren't part of the VM on release
    - LP: #1465696
  * drm/radeon: reset BOs address after clearing it.
    - LP: #1465696
  * drm/radeon: check new address before removing old one
  ...

This bug was fixed in the package linux - 3.16.0-43.58

---------------
linux (3.16.0-43.58) utopic; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1466792

  [ Brad Figg ]

  * Merged back Ubuntu-3.16.0-41.57 regression fix for security release

linux (3.16.0-42.56) utopic; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1465714

  [ Chris J Arges ]

  * [config] CONFIG_IPMI_POWERNV=m on ppc64el
    - LP: #1439562

  [ Luis Henriques ]

  * [Config] Disable CONFIG_USB_OTG
    - LP: #1411295

  [ Upstream Kernel Changes ]

  * Revert "i2c: Mark adapter devices with pm_runtime_no_callbacks"
    - LP: #1465613
  * Revert "mm/hugetlb: use pmd_page() in follow_huge_pmd()"
    - LP: #1465613
  * cdc-acm: prevent infinite loop when parsing CDC headers.
    - LP: #1460657
  * drivers/char/ipmi: Add powernv IPMI driver
    - LP: #1439562
  * powerpc/powernv: Add OPAL IPMI interface
    - LP: #1439562
  * powerpc/powernv: Support OPAL requested heartbeat
    - LP: #1439562
  * powerpc/kernel: Make syscall_exit a local label
    - LP: #1439562
  * powerpc: Remove old compile time disabled syscall tracing code
    - LP: #1439562
  * powerpc/powernv: Remove "opal" prefix from pr_xxx()s
    - LP: #1439562
  * powerpc/powernv: Separate function for OPAL IRQ setup
    - LP: #1439562
  * powerpc/powernv: Add OPAL message notifier unregister function
    - LP: #1439562
  * device: Add dev_of_node() accessor
    - LP: #1439562
  * drivers/core/of: Add symlink to device-tree from devices with an OF
    node
    - LP: #1439562
  * powerpc: Add a proper syscall for switching endianness
    - LP: #1439562
  * (upstream) libata: Blacklist queued TRIM on all Samsung 800-series
    - LP: #1338706, #1449005
  * ahci: avoton port-disable reset-quirk
    - LP: #1458617
  * udf: Remove repeated loads blocksize
    - LP: #1462173
    - CVE-2015-4167
  * udf: Check length of extended attributes and allocation descriptors
    - LP: #1462173
    - CVE-2015-4167
  * (upstream)scsi_lib: remove the description string in
    scsi_io_completion()
    - LP: #1449372
  * vfs: read file_handle only once in handle_to_path
    - LP: #1416503
    - CVE-2015-1420
  * ozwpan: Use unsigned ints to prevent heap overflow
    - LP: #1463442
    - CVE-2015-4001
  * ozwpan: divide-by-zero leading to panic
    - LP: #1463445
    - CVE-2015-4003
  * ozwpan: Use proper check to prevent heap overflow
    - LP: #1463444
    - CVE-2015-4002
  * ozwpan: unchecked signed subtraction leads to DoS
    - LP: #1463444
    - CVE-2015-4002
  * net: eth: xgene: devm_ioremap() returns NULL on error
    - LP: #1458042
  * drivers: net: xgene: fix new firmware backward compatibility with older
    driver
    - LP: #1458042
  * drivers: net: xgene: constify of_device_id array
    - LP: #1458042
  * drivers: net: xgene: Add second SGMII based 1G interface
    - LP: #1458042
  * dtb: change binding name to match with newer firmware DT
    - LP: #1458042
  * dtb: xgene: Add second SGMII based 1G interface node
    - LP: #1458042
  * mlx4: Fix tx ring affinity_mask creation
    - LP: #1465613
  * net/mlx4_en: Schedule napi when RX buffers allocation fails
    - LP: #1465613
...

This bug was fixed in the package linux - 3.13.0-57.95

---------------
linux (3.13.0-57.95) trusty; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1466592

  [ Brad Figg ]

  * Merged back Ubuntu-3.13.0-55.94 regression fix for security release

linux (3.13.0-56.93) trusty; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1465798

  [ Upstream Kernel Changes ]

  * net: eth: xgene: devm_ioremap() returns NULL on error
    - LP: #1458042
  * drivers: net: xgene: fix new firmware backward compatibility with older
    driver
    - LP: #1458042
  * drivers: net: xgene: constify of_device_id array
    - LP: #1458042
  * drivers: net: xgene: Add second SGMII based 1G interface
    - LP: #1458042
  * net: phy: re-design phy_modes to be self-contained
    - LP: #1458042
  * dtb: change binding name to match with newer firmware DT
    - LP: #1458042
  * dtb: xgene: Add second SGMII based 1G interface node
    - LP: #1458042
  * Btrfs: make xattr replace operations atomic
    - LP: #1438501
    - CVE-2014-9710
  * cdc-acm: prevent infinite loop when parsing CDC headers.
    - LP: #1460657
  * (upstream) libata: Blacklist queued TRIM on all Samsung 800-series
    - LP: #1338706, #1449005
  * ahci: avoton port-disable reset-quirk
    - LP: #1458617
  * xfs: avoid false quotacheck after unclean shutdown
    - LP: #1461730
  * (upstream)[SCSI] Add timeout to avoid infinite command retry
    - LP: #1449372
  * (upstream)scsi_lib: remove the description string in
    scsi_io_completion()
    - LP: #1449372
  * udf: Remove repeated loads blocksize
    - LP: #1462173
    - CVE-2015-4167
  * udf: Check length of extended attributes and allocation descriptors
    - LP: #1462173
    - CVE-2015-4167
  * vfs: read file_handle only once in handle_to_path
    - LP: #1416503
    - CVE-2015-1420
  * ozwpan: Use unsigned ints to prevent heap overflow
    - LP: #1463442
    - CVE-2015-4001
  * ozwpan: divide-by-zero leading to panic
    - LP: #1463445
    - CVE-2015-4003
  * ozwpan: Use proper check to prevent heap overflow
    - LP: #1463444
    - CVE-2015-4002
  * ozwpan: unchecked signed subtraction leads to DoS
    - LP: #1463444
    - CVE-2015-4002
  * Input: elantech - add new icbody type
    - LP: #1464490
  * Bluetooth: ath3k: Add support Atheros AR5B195 combo Mini PCIe card
    - LP: #1465796
  * power_supply: twl4030_madc: Check return value of power_supply_register
    - LP: #1465796
  * power_supply: lp8788-charger: Fix leaked power supply on probe fail
    - LP: #1465796
  * ARM: dts: dove: Fix uart[23] reg property
    - LP: #1465796
  * xtensa: xtfpga: fix hardware lockup caused by LCD driver
    - LP: #1465796
  * Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
    - LP: #1465796
  * xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range
    - LP: #1465796
  * KVM: s390: Zero out current VMDB of STSI before including level3 data.
    - LP: #1465796
  * usb: musb: core: fix TX/RX endpoint order
    - LP: #1465796
  * drm/radeon: fix doublescan modes (v2)
    - LP: #1465796
  * usb: phy: Find the right match in devm_usb_phy_match
    - LP: #1465796
  * tools lib traceevent kbuffer: Rem...

Hi All,
then the kernel 3.13 has the fix, but what about the 3.16 used as default kernel in Linux MINT 17.2 "Rafaela" ???
Will be available a 3.16-xxx that fix th bug??
In the meantime is better to don't do fstrim???

@fabiocasi

As far as I understand updated ubuntu kernels are available in mint as I think they pull from the same archives. Why don't you try enabling proposed and checking since you are clearly running mint. Also per comment 75 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706/comments/75
This has also been fixed in 3.16.

Having same problem on kernel 3.19.0-25-generic/Ubuntu 15.04 and no solution so far. :((

[ 0.553706] ata5: SATA max UDMA/133 abar m2048@0xf3216000 port 0xf3216300 irq 26
[ 0.872359] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 0.873019] ata5.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 0.873021] ata5.00: ATA-9: Samsung SSD 840 Series, DXT06B0Q, max UDMA/133
[ 0.873022] ata5.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 0.873048] ata5.00: failed to get Identify Device Data, Emask 0x1
[ 0.873308] ata5.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 0.873330] ata5.00: failed to get Identify Device Data, Emask 0x1
[ 0.873332] ata5.00: configured for UDMA/133
[ 1.119711] ata5.00: Enabling discard_zeroes_data
[ 1.119981] ata5.00: Enabling discard_zeroes_data
[ 1.120717] ata5.00: Enabling discard_zeroes_data

Seems Samsung fixed this bug in kernel (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc) and blacklist is no longer needed. Maybe we should remove blacklist and apply this patch instead?

On 08/12/2015 03:59 AM, Andrei Demin wrote:
> Seems Samsung fixed this bug in kernel
> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3f5da624e0a891c34d8cd513c57f1d9b0c7dadc)
> and blacklist is no longer needed. Maybe we should remove blacklist and
> apply this patch instead?
>

I don't see how that fix applies to any of the error messages we are seeing.

This patch from Samsung fixes trim bug in kernel.
1. http://techreport.com/news/28674/samsung-says-data-eating-trim-bug-is-a-linux-kernel-problem
2. http://www.spinics.net/lists/raid/msg49440.html

Or this patch fixes another trim bug... Then i'm sorry.
"The queued TRIM issue with Samsung drives remains open but it has nothing whatsoever to do with the Algolia bug." http://techreport.com/news/28724/samsung-docs-detail-linux-trim-bug-and-fix

Yes, it's a different issue. Algolia weren't even using queues TRIM.

@Andrei Demin,
Have you opened a separate case for Samsung drives + RAID 0 + trim = corruption? If so what is that bug number?

@Dave Chiluk
No, I didn't. I have no that configuration.

I think it is still there in a fresh Wily install ....

uname -a
Linux john-Aspire-X3812 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

dmesg | grep ata4
[ 6846.008190] ata4: hard resetting link
[ 6846.328019] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 6846.329593] ata4.00: supports DRM functions and may not be fully accessible
[ 6846.329708] ata4.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 6846.330094] ata4.00: supports DRM functions and may not be fully accessible
[ 6846.330161] ata4.00: failed to get NCQ Send/Recv Log Emask 0x1
[ 6846.330260] ata4.00: configured for UDMA/133
[ 6846.330286] ata4: EH complete
[15551.012030] ata4.00: exception Emask 0x10 SAct 0xf000 SErr 0x400100 action 0x6 frozen
[15551.012035] ata4.00: irq_stat 0x08000000, interface fatal error
[15551.012039] ata4: SError: { UnrecovData Handshk }
[15551.012042] ata4.00: failed command: WRITE FPDMA QUEUED
[15551.012048] ata4.00: cmd 61/08:60:e8:98:75/00:00:01:00:00/40 tag 12 ncq 4096 out
                        res 40/00:68:30:99:44/00:00:09:00:00/40 Emask 0x10 (ATA bus error)
[15551.012051] ata4.00: status: { DRDY }

JohnShep, as this report is closed, if you are having an issue, you will want to file a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on this, please see https://wiki.ubuntu.com/ReportingBugs.

Hi Chris,
I filed the bug, sorry I don't know how to subscribe you to it ...

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1530459

all the best, John

On 1 January 2016 at 05:02, Christopher M. Penalver
<email address hidden> wrote:
> JohnShep, as this report is closed, if you are having an issue, you will want to file a new report via a terminal:
> ubuntu-bug linux
>
> Please feel free to subscribe me to it.
>
> For more on this, please see https://wiki.ubuntu.com/ReportingBugs.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1338706
>
> Title:
> Samsung SSD 840 failed to get NCQ Send/Recv Log Emask 0x1 failed to
> set xfermode (err_mask=0x40) on upstream kernels >= 3.12
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706/+subscriptions

Does this result in anyone not being able to suspend?

@evan

No, you are seeing a different or new bug.

Can any one check if Queued TRIM issue is resolved in EXM03B6Q firmware (available as of October 2016) for 850 Pro?
I'm not expecting Queued TRIM to work properly, but may be it is not advertised as supported any more?