From: Brian Norris <computersforpeace@gmail.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Huang Shijie <b32955@freescale.com>,
Brian Norris <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org
Subject: [PATCH 3/3] mtd: cfi_cmdset_0002: increase do_write_buffer() timeout
Date: Mon, 3 Jun 2013 18:46:46 -0700 [thread overview]
Message-ID: <1370310406-413-3-git-send-email-computersforpeace@gmail.com> (raw)
In-Reply-To: <1370310406-413-1-git-send-email-computersforpeace@gmail.com>
I have seen various failures like this while doing a simple reboot +
mount UBIFS test:
UBIFS: recovery needed
MTD do_write_buffer(): software timeout
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 365:43648, written 192 bytes
(This message doens't exactly match the message in the current head of
tree, as Huang edited the timeout message.)
I'm using a 64Mbyte Spansion S29GL512 NOR flash. I've also seen reports
of the same failure on Micron 128Mbyte NOR flash AM29EWLD.
After various tests, it seems simply that the timeout is not long enough
for my system; increasing it by a few jiffies prevented all failures
(testing for 12+ hours). There is no harm in increasing the timeout, but
there is harm in having it too short, as evidenced here.
This patch increases the timeout value in 3 locations, as they all are
referencing the do_write_oneword function. I have only ever seen the
timeout in do_write_buffer().
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
drivers/mtd/chips/cfi_cmdset_0002.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c
index 4e28081..45de025 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -1228,14 +1228,11 @@ static int __xipram do_write_oneword(struct map_info *map, struct flchip *chip,
struct cfi_private *cfi = map->fldrv_priv;
unsigned long timeo;
/*
- * We use a 1ms generic timeout for writes (most devices have a max
- * write time of a few hundreds usec). However, we should use the
- * maximum timeout value given by the chip at probe time instead.
- * Unfortunately, struct flchip does have a field for maximum timeout,
- * only for typical which can be far too short depending of the
- * conditions.
+ * We use a 10ms generic timeout for writes. Most devices have a max
+ * write time of a few hundreds usec, but timeouts have been seen with
+ * too few jiffies.
*/
- unsigned long uWriteTimeout = msecs_to_jiffies(1);
+ unsigned long uWriteTimeout = msecs_to_jiffies(10);
int ret = 0;
map_word oldd;
int retry_cnt = 0;
@@ -1465,7 +1462,7 @@ static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip,
struct cfi_private *cfi = map->fldrv_priv;
unsigned long timeo;
/* see comments in do_write_oneword() regarding uWriteTimeout */
- unsigned long uWriteTimeout = msecs_to_jiffies(1);
+ unsigned long uWriteTimeout = msecs_to_jiffies(10);
int ret = -EIO;
unsigned long cmd_adr;
int z, words;
@@ -1716,7 +1713,7 @@ static int cfi_amdstd_panic_wait(struct map_info *map, struct flchip *chip,
static int do_panic_write_oneword(struct map_info *map, struct flchip *chip,
unsigned long adr, map_word datum)
{
- const unsigned long uWriteTimeout = msecs_to_jiffies(1);
+ const unsigned long uWriteTimeout = msecs_to_jiffies(10);
struct cfi_private *cfi = map->fldrv_priv;
int retry_cnt = 0;
map_word oldd;
--
1.8.2.3
next prev parent reply other threads:[~2013-06-04 1:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-04 1:46 [PATCH 1/3] mtd: cfi_cmdset_0002: remove unnecessary initialization Brian Norris
2013-06-04 1:46 ` [PATCH 2/3] mtd: cfi_cmdset_0002: use msecs_to_jiffies() macro Brian Norris
2013-06-04 1:46 ` Brian Norris [this message]
2013-06-04 7:03 ` [PATCH 3/3] mtd: cfi_cmdset_0002: increase do_write_buffer() timeout Huang Shijie
2013-06-05 18:01 ` Brian Norris
2013-06-05 21:08 ` Brian Norris
2013-06-05 22:39 ` Imre Deak
2013-06-06 2:20 ` Huang Shijie
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=1370310406-413-3-git-send-email-computersforpeace@gmail.com \
--to=computersforpeace@gmail.com \
--cc=b32955@freescale.com \
--cc=dedekind1@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).