kernel-packages team mailing list archive

[Mark Rein <gimpsmart@xxxxxxxxxxxx>]

Turns out this "I support Queued TRIM!" issue is a year old and affected the entire previous generation too:
Discovered by kernel devs in the 840 Pro and 840 Evo: https://bugzilla.kernel.org/show_bug.cgi?id=72341
and also discussed here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706

Here is another brand (WD) doing the same thing in late 2013:
http://lists.infradead.org/pipermail/linux-arm-
kernel/2013-October/203508.html


The bottom line is: Samsung SSDs firmware have been updated to SATA 3.2 spec, which includes Queued TRIM, and they advertise that they support it, but in reality the firmware doesn't process those queued trims properly and seems to eat random blocks instead, thus destroying random data.


>From what I understand from the first link (see comment 48), these drives set "ATA IDENTIFY's word 77, bit 6" to 1, which means "RECEIVE/SEND FPDMA QUEUED supported". That "FPDMA QUEUED" is the thing used to send a queued TRIM. The firmware does not actually support RECV/SEND FPDMA QUEUED, and just wrongly claims that it does. If you try to retrieve "log 13h" the drive errors out, but the spec says that if RECV/SEND FPDMA is supported then log 13h MUST also be supported. So this is a clear case of Samsung's firmware department ticking a flag for all the shiny SATA 3.2 features, and not actually making sure they implemented them all. Very, very shoddy.


Since this problem affects all modern Samsung SSDs, it's really up to Samsung to fix their firmware. It's NOT up to the operating systems to blacklist misbehaving drives. Are we really gonna have to wait until Windows does Queued TRIM and millions of people lose data, for them to react to their broken firmware?


It has proven futile to talk to Samsung via their regular support contact form. This bug report needs to come from someone with better access to intelligent humans at Samsung (they must exist, right?). I know of only two people with "direct access" to Samsung firmware people:
- Marc Carino < marc.ceeeee [at] gmail.com >, who wrote in kernel.org bug #72341 on 2014-05, that he was reaching out to Samsung's firmware department about the problem.
- Martin K. Petersen from Oracle < martin.petersen [at] oracle.com >, who wrote on the kernel mailing list on 2015-05-04 about contacting Samsung.


** Bug watch added: Linux Kernel Bug Tracker #72341
   http://bugzilla.kernel.org/show_bug.cgi?id=72341

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1449005

Title:
  trim does not work with Samsung 840 EVO after firmware update
  (EXT0DB6Q)

Status in fstrim package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed
Status in fstrim source package in Trusty:
  Invalid
Status in linux source package in Trusty:
  Confirmed
Status in fstrim source package in Utopic:
  Invalid
Status in linux source package in Utopic:
  Confirmed
Status in fstrim source package in Vivid:
  Invalid
Status in linux source package in Vivid:
  Confirmed

Bug description:
  Hi,
  after updating Samsung SSD 840 EVO to the latest firmware (EXT0DB6Q) the fstream command doesn't work anymore. Besides, there are a lot of file system errors and "bad sectors" reports. The problem is certainly caused by Samsung's firmware but I reported it as a bug because in Windows TRIM works normally after the upgrade. I have attached an image uploaded by a user who is experiencing the same problem. If you execute the command "sudo fstrim /" the  console gets stuck. If you add that command in rc.local the boot is compromised. I really hope this problem could be solved.
  Thanks

  ===
  break-fix: - 6fc4d97a4987c5d247655a157a9377996626221a
  break-fix: - 9a9324d3969678d44b330e1230ad2c8ae67acf81

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005/+subscriptions