From: Artem Bityutskiy <dedekind1@gmail.com>
To: David Peverley <pev@sketchymonkey.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Testing a device using mtd_stresstest
Date: Sun, 06 Feb 2011 16:24:41 +0200 [thread overview]
Message-ID: <1297002281.4460.6.camel@localhost> (raw)
In-Reply-To: <AANLkTikxCVO5Qs4amo1cCgnYVD3fYZdKh2in4e+X5EFV@mail.gmail.com>
Hi,
On Mon, 2011-01-31 at 12:12 +0000, David Peverley wrote:
> Question 1 : The mtd_subpagetest (which I suspect should fail as the
> device doesn't support sub-pages). I googled around and found a
> reference that maybe I should add NAND_NO_SUBPAGE_WRITE to the
> options. I tried this and it made no difference. Out of curiosity I
> grepped through drivers/mtd and found that *no* drivers actully use
> this bit anyway...! Is it reasonable to ignore this or ought I address
> it? Should I set the flag and expect it to have an effect?
MTD code is currently broken and CONFIG_MTD_NAND_VERIFY_WRITE causes
errors when sub-pages are used. You should either disable this
configuration option or fix MTD. We have this in our FAQ:
http://www.linux-mtd.infradead.org/faq/ubi.html#L_subpage_verify_fail
> Question 2 : The mtd_stresstest test fails after anywhere between 1000
> and 200,000 operations. I'm certain this is a Bad Sign. It fails in
> nand_base.c:nand_write_page() in the verification step enabled by
> MTD_NAND_VERIFY_WRITE. When I tested this on our previous board (that
> ostensibly works fine) it failed the stress test after 2.6M operations
> instead. Should I be expecting to never see a failure of the stress
> test or is an occasional verify failure reasonably expected?
Yes, the test is expected to never fail. You should try to dig and
understand why is it failing and what is the reason.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2011-02-06 14:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 12:12 Testing a device using mtd_stresstest David Peverley
2011-02-06 14:24 ` Artem Bityutskiy [this message]
2011-02-07 13:44 ` David Peverley
2011-02-07 14:01 ` Andrew Murray
2011-02-07 14:39 ` Arno Steffen
2011-02-10 15:24 ` David Peverley
2011-02-18 10:59 ` Arno Steffen
[not found] ` <AANLkTi=UgsLq3=7ma9MPJJBVxtNvyr=ThtLPy8qzC3Bk@mail.gmail.com>
2011-02-10 12:30 ` David Peverley
[not found] ` <AANLkTimJFv1Uy2c70ewPUHYH58rQHT=VsDa3ioU9hJZh@mail.gmail.com>
2011-02-11 14:25 ` David Peverley
2011-02-11 15:16 ` Artem Bityutskiy
2011-02-11 16:42 ` David Peverley
2011-02-11 15:12 ` Artem Bityutskiy
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=1297002281.4460.6.camel@localhost \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pev@sketchymonkey.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox