kernel-packages team mailing list archive

[Mark Rein <gimpsmart@xxxxxxxxxxxx>]

*** This bug is a duplicate of bug 1338706 ***
    https://bugs.launchpad.net/bugs/1338706

My final attempt at contacting Samsung's braindead support monkeys, this
time without any mention of the word "trim", and I decided to lie and
say that I'm a hardware controller manufacturer who discovered the flaw
to hopefully get the monkey to take notice. Let's see the support
monkeys screw this up again - I am SURE they will, as they've repeatedly
done so for *every one of us* who has tried contacting them. And if/when
that happens, I'll do one last effort and take this up with the two guys
above who have direct contacts at Samsung, who can bypass the monkey
brigade.

---

I am working on programming a new hardware RAID controller, and one of
my test disks is a Samsung 850 PRO 500gb which shipped with firmware
EXM02B6Q from the factory.

During my testing, I probe all the drives and discovered that your
firmware revision includes SATA 3.2 spec features, but that they are not
properly implemented.

The drive sets "ATA IDENTIFY's" word 77, bit 6 to 1 ("true"), which
means "RECEIVE/SEND FPDMA QUEUED supported".

But 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 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.

The false advertisement of ATA IDENTIFY word 77 bit 6, without actually
supporting that new feature, means that the drive is severely broken in
multiple ways.

Two possible solutions to this situation:
1) A firmware update which sets "ATA IDENTIFY's" word 77, bit 6 to 0 ("FALSE!") instead, to PROPERLY show that the drive does NOT support SATA 3.2 FPDMA QUEUED features.
2) Alternatively, a firmware update which implements FPDMA QUEUED, log 13h, etc, so that the drive actually supports what it *claims* it does.

Of these two, #1 is the easiest and makes the most sense. Either way,
there's a problem in the firmware and it needs a fix.

Thank you for your time,

Richard

-- 
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:
  Fix Committed
Status in fstrim source package in Utopic:
  Invalid
Status in linux source package in Utopic:
  Fix Committed
Status in fstrim source package in Vivid:
  Invalid
Status in linux source package in Vivid:
  Fix Committed

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