All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atlant Schmidt <aschmidt@dekaresearch.com>
To: "'linux-mtd@lists.infradead.org'" <linux-mtd@lists.infradead.org>
Subject: I don't understand how the counter for erasures is being maintained during erase failures
Date: Tue, 12 Apr 2011 08:57:05 -0400	[thread overview]
Message-ID: <0A40042D85E7C84DB443060EC44B3FD328119F6E7D@dekaexchange07.deka.local> (raw)

Folks:

On my linux system (running MTD/UBI/UBIfs), the following
event occurred:


  [62452.439299] UBI error: ubi_io_write: error -5 while writing 516096 bytes to PEB 3982:8192, written 503808 bytes
  [62452.465874] UBI: run torture test for PEB 3982
  [62463.910000] UBI: PEB 3982 passed torture test, do not mark it a bad
  [62466.666439] UBI error: ubi_io_write: error -5 while writing 516096 bytes to PEB 3982:8192, written 503808 bytes
  [62466.693753] UBI: run torture test for PEB 3982
  [62477.763592] UBI: PEB 3982 passed torture test, do not mark it a bad
    :
    :
  [62622.746585] UBI error: ubi_io_write: error -5 while writing 516096 bytes to PEB 3982:8192, written 503808 bytes
  [62622.801612] UBI: run torture test for PEB 3982
  [62633.821650] UBI: PEB 3982 passed torture test, do not mark it a bad
  [62636.629686] UBI error: ubi_io_write: error -5 while writing 516096 bytes to PEB 3982:8192, written 503808 bytes
  [62636.661260] UBI: run torture test for PEB 3982
  [62643.962758] UBI error: torture_peb: read problems on freshly erased PEB 3982, must be bad
  [62643.992792] UBI error: erase_worker: failed to erase PEB 3982, error -5
  [62644.022791] UBI: mark PEB 3982 as bad
  [62644.045182] UBI: 37 PEBs left in the reserve


At this point, I dumped out the contents of PEB 3982:

  /> ubi_dump.pl 3982
  PEB f8e (3982):  ec magic number is not correct. Is: 5a5a5a5a   Should be: 55424923
  PEB 3982:
    00000000:   5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
    00000020:   5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
    00000040:   5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
    00000060:   5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A 5A5A5A5A  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
      :
      :


So that PEB no longer contains any ubi_ec_hdr struct.

What happens next?

When I reboot, this block *HASN'T* been added to the bad block
list (nor were the other two blocks "marked as bad" during this
linux boot session). And after the reboot, my script reports
the following information about PEB 3982:

  /> ubi_dump.pl 3982
  PEB f8e (3982):  Erased 16
  Minimum erase count: 16
  Average erase count: 16 computed across 1 blocks
  Maximum erase count: 16


This can't be accurate -- the block was tortured 14 times
during the failure and each torture represents three erase/
write cycles, right? (Per torture_peb(), OxA5, 0x5A, and 0x00.)
So even if this block had somehow been "virgin" (and it's
certainly not!), it should now have an erase count of at
least 3*14=42, just considering the torturing.

Also, given that it failed to erase (or at least couldn't be
successfully read when freshly erased), why doesn't the block
permanently join the pool of bad PEBs?

                           Atlant


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.

             reply	other threads:[~2011-04-12 12:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-12 12:57 Atlant Schmidt [this message]
2011-04-14  7:13 ` I don't understand how the counter for erasures is being maintained during erase failures Artem Bityutskiy
2011-04-14 10:53   ` Atlant Schmidt
2011-04-14 10:55     ` Artem Bityutskiy
2011-04-14 10:58       ` Atlant Schmidt
2011-04-14 11:35     ` Artem Bityutskiy
2011-04-14 11:53       ` Atlant Schmidt

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=0A40042D85E7C84DB443060EC44B3FD328119F6E7D@dekaexchange07.deka.local \
    --to=aschmidt@dekaresearch.com \
    --cc=linux-mtd@lists.infradead.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.