All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mitch Bradley <wmb@laptop.org>
To: linux-mmc@vger.kernel.org
Subject: SD cards die when power is removed
Date: Wed, 15 Sep 2010 19:25:57 -1000	[thread overview]
Message-ID: <4C91AA65.5080802@laptop.org> (raw)

  At One Laptop Per Child we recently ran afoul of an ugly problem with some 8GB SD cards.  It turns out that the cards 
can die if you turn off power sooner than 1.6 seconds after a write.  That 1.6 seconds is measured from after the SD bus 
has already said "that programming step is done".

After some discussion with the vendor, we learned that this is an artifact of the way they are handling the TLC (three 
level cell) array.  The write first goes into a cache that is written in SLC (single level cell) mode, then is moved 
into the TLC "backing store".  If you turn off power during the write-back, the device can fail so badly that you have 
to use a special machine to recover it.

The 1.6 seconds is not documented anywhere, and is not discoverable by reading card configuration or status information.

OLPC can suspend so quickly that we can easily run afoul of this problem.

Clearly, this is bad firmware in the controller, but it does bring up an interesting point.  As FLASH devices get more 
and more complex, the necessity of doing background housekeeping increases.  Ideally, the algorithms should be safe 
against power loss, but on the other hand, it would also be a good idea to give controllers a chance to shut down 
gracefully when the OS knows it is about to turn off power.

Does anybody know of any standardization efforts to address the "clean shutdown" issue for SD or other FLASH interfaces?

Mitch Bradley


                 reply	other threads:[~2010-09-16  5:32 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C91AA65.5080802@laptop.org \
    --to=wmb@laptop.org \
    --cc=linux-mmc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.