From: Holger Brunck <holger.brunck@keymile.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] UBI: fix endless loop when a bitflip was detected
Date: Wed, 21 Sep 2011 11:08:58 +0200 [thread overview]
Message-ID: <4E79A9AA.5010706@keymile.com> (raw)
In-Reply-To: <1315904833-11430-1-git-send-email-holger.brunck@keymile.com>
On 09/13/2011 11:07 AM, Holger Brunck wrote:
> On km_kirkwood boards we saw that u-boot gets stuck if the
> UBI layer detects a correctable bitflip in the NAND flash
> when u-boot tries to attach to the UBI device.
>
> This was already fixed in the UBI layer in the current
> mainline linux. The original commit was:
>
> "commit b86a2c56e512f46d140a4bcb4e35e8a7d4a99a4b
> Author: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
> Date: Sun May 24 14:13:34 2009 +0300
>
> UBI: do not switch to R/O mode on read errors
>
> This patch improves UBI errors handling. ATM UBI switches to
> R/O mode when the WL worker fails to read the source PEB.
> This means that the upper layers (e.g., UBIFS) has no
> chances to unmap the erroneous PEB and fix the error.
> This patch changes this behaviour and makes UBI put PEBs
> like this into a separate RB-tree, thus preventing the
> WL worker from hitting the same read errors again and
> again.
>
> But there is a 10% limit on a maximum amount of PEBs like this.
> If there are too much of them, UBI switches to R/O mode.
>
> Additionally, this patch teaches UBI not to panic and
> switch to R/O mode if after a PEB has been copied, the
> target LEB cannot be read back. Instead, now UBI cancels
> the operation and schedules the target PEB for torturing.
>
> The error paths has been tested by ingecting errors
> into 'ubi_eba_copy_leb()'."
>
> This patch is the portation to u-boot with some changes. The
> constants for errors used in the original patch were replaced
> with numeric values as present in current ubi layer. The constant
> "MOVE_TARGET_RD_ERR" was removed from the original patch because
> the current u-boot version didn't evaluate this value.
>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> cc: Stefan Roese <sr@denx.de>
> ---
> drivers/mtd/ubi/build.c | 9 +++++++++
> drivers/mtd/ubi/eba.c | 8 ++++++--
> drivers/mtd/ubi/ubi.h | 10 ++++++++--
> drivers/mtd/ubi/wl.c | 43 +++++++++++++++++++++++++++++++++++++------
> 4 files changed, 60 insertions(+), 10 deletions(-)
>
please drop this patch. I was wrong, see:
http://lists.denx.de/pipermail/u-boot/2011-September/101887.html
Best regards
Holger
next prev parent reply other threads:[~2011-09-21 9:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 9:07 [U-Boot] [PATCH] UBI: fix endless loop when a bitflip was detected Holger Brunck
2011-09-21 9:08 ` Holger Brunck [this message]
2011-10-06 21:32 ` Wolfgang Denk
2011-10-07 7:39 ` Holger Brunck
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=4E79A9AA.5010706@keymile.com \
--to=holger.brunck@keymile.com \
--cc=u-boot@lists.denx.de \
/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.