All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Harvey Hunt <harvey.hunt@imgtec.com>
Cc: IMG-MIPSLinuxKerneldevelopers@imgtec.com,
	Alex Smith <alex.smith@imgtec.com>,
	Alex Smith <alex@alex-smith.me.uk>,
	Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Niklas Cassel <niklas.cassel@axis.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7] mtd: nand: increase ready wait timeout and report timeouts
Date: Mon, 26 Oct 2015 13:05:31 -0700	[thread overview]
Message-ID: <20151026200531.GE13239@google.com> (raw)
In-Reply-To: <1444139527-14087-1-git-send-email-harvey.hunt@imgtec.com>

On Tue, Oct 06, 2015 at 02:52:07PM +0100, Harvey Hunt wrote:
> From: Alex Smith <alex.smith@imgtec.com>
> 
> If nand_wait_ready() times out, this is silently ignored, and its
> caller will then proceed to read from/write to the chip before it is
> ready. This can potentially result in corruption with no indication as
> to why.
> 
> While a 20ms timeout seems like it should be plenty enough, certain
> behaviour can cause it to timeout much earlier than expected. The
> situation which prompted this change was that CPU 0, which is
> responsible for updating jiffies, was holding interrupts disabled
> for a fairly long time while writing to the console during a printk,
> causing several jiffies updates to be delayed. If CPU 1 happens to
> enter the timeout loop in nand_wait_ready() just before CPU 0 re-
> enables interrupts and updates jiffies, CPU 1 will immediately time
> out when the delayed jiffies updates are made. The result of this is
> that nand_wait_ready() actually waits less time than the NAND chip
> would normally take to be ready, and then read_page() proceeds to
> read out bad data from the chip.
> 
> The situation described above may seem unlikely, but in fact it can be
> reproduced almost every boot on the MIPS Creator Ci20.
> 
> Therefore, this patch increases the timeout to 400ms. This should be
> enough to cover cases where jiffies updates get delayed. In nand_wait()
> the timeout was previously chosen based on whether erasing or
> programming. This is changed to be 400ms unconditionally as well to
> avoid similar problems there. nand_wait() is also slightly refactored
> to be consistent with nand_wait{,_status}_ready(). These changes should
> have no effect during normal operation.
> 
> Debugging this was made more difficult by the misleading comment above
> nand_wait_ready() stating "The timeout is caught later" - no timeout was
> ever reported, leading me away from the real source of the problem.
> Therefore, a pr_warn() is added when a timeout does occur so that it is
> easier to pinpoint similar problems in future.
> 
> Signed-off-by: Alex Smith <alex.smith@imgtec.com>
> Signed-off-by: Harvey Hunt <harvey.hunt@imgtec.com>
> Reviewed-by: Niklas Cassel <niklas.cassel@axis.com>
> Cc: Alex Smith <alex@alex-smith.me.uk>
> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Brian Norris <computersforpeace@gmail.com>
> Cc: Niklas Cassel <niklas.cassel@axis.com>
> Cc: linux-mtd@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> This patch was originally sent in a JZ4780 patch set, but sending
> it on its own was deemed more appropriate. Alex Smith sent the
> original patch - this is an unmodified version that he has asked me
> to send.

Looks good, thanks. Pushed to l2-mtd.git.

  reply	other threads:[~2015-10-26 20:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06 13:52 [PATCH v7] mtd: nand: increase ready wait timeout and report timeouts Harvey Hunt
2015-10-26 20:05 ` Brian Norris [this message]
2016-02-25 22:54 ` Richard Weinberger
2016-02-25 23:14   ` Brian Norris
2016-02-25 23:23     ` Boris Brezillon
2016-02-25 23:27       ` Richard Weinberger
2016-02-26 13:45         ` Harvey Hunt

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=20151026200531.GE13239@google.com \
    --to=computersforpeace@gmail.com \
    --cc=IMG-MIPSLinuxKerneldevelopers@imgtec.com \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=alex.smith@imgtec.com \
    --cc=alex@alex-smith.me.uk \
    --cc=dwmw2@infradead.org \
    --cc=harvey.hunt@imgtec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=niklas.cassel@axis.com \
    /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.