From: Huang Shijie <b32955@freescale.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org, Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH 3/3] mtd: cfi_cmdset_0002: increase do_write_buffer() timeout
Date: Tue, 4 Jun 2013 15:03:28 +0800 [thread overview]
Message-ID: <51AD9140.90500@freescale.com> (raw)
In-Reply-To: <1370310406-413-3-git-send-email-computersforpeace@gmail.com>
于 2013年06月04日 09:46, Brian Norris 写道:
> 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.
>
I like the patch1 and patch 2.
But extending the timeout from 1ms to 10ms is like a workaround. :)
>From the NOR's spec, even the maximum write-to-buffer only costs several
hundreds us,
such as 200us.
I GUESS your problem is caused by the timer system, not the MTD code. I
ever met this type of bug.
The bug is in the kernel 3.5.7, but the latest kernel has fixed it with
NO_HZ_IDLE/NO_HZ_COMMON features.
I do not meet the issue the latest linux-next tree.
I try to describe the jiffies bug with my poor english:
[1] background:
CONFIG_HZ=100, CONFIG_NO_HZ=y
[2] call nand_wait() when we write a nand page.
[3] The jiffies was not updated at a _even_ speed.
In the nand_wait(), you wait for 20ms(2 jiffies) for a page write,
and the timeout occurs during the page write. Of course, you think that
we have already waited for 20ms.
But in actually, we only waited for 1ms or less!
How do i know this? I use the gettimeofday to check the real time when
the timeout occur.
[4] if i disable the local timer, the bug disappears.
So, could you check the real time when the timeout occurs?
Btw: My NOR's timeout is proved to be a silicon bug by Micron.
thanks
Huang Shijie
next prev parent reply other threads:[~2013-06-04 7:01 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 ` [PATCH 3/3] mtd: cfi_cmdset_0002: increase do_write_buffer() timeout Brian Norris
2013-06-04 7:03 ` Huang Shijie [this message]
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=51AD9140.90500@freescale.com \
--to=b32955@freescale.com \
--cc=computersforpeace@gmail.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).