linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: JerinJacob <jerin.jacob@maxim-ic.com>
To: "dedekind1@gmail.com" <dedekind1@gmail.com>
Cc: "Artem.Bityutskiy@nokia.com" <Artem.Bityutskiy@nokia.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Hunter Adrian \(Nokia-D/Helsinki\)" <adrian.hunter@nokia.com>
Subject: Re: UBIFS Error
Date: Tue, 15 Sep 2009 13:58:06 +0530	[thread overview]
Message-ID: <4AAF5016.2030809@maxim-ic.com> (raw)
In-Reply-To: <1252938588.5060.103.camel@localhost>

I've created this piece of documentation for you:
http://www.linux-mtd.infradead.org/doc/general.html#L_mtd_tests

Please, validate your flash driver/HW.

>> Got a crash  while reading a large mtd device with "mtd_readtest".
Let me fix this platform specific driver bug.
Any way this mtd_tests are very use full.
 
And here is the text in case someone would review it:

 >> you may add how to run the test.
 >> modprobe mtd_readtest dev=6 ; rmmod mtd_readtest


Artem Bityutskiy wrote:
> On Mon, 2009-09-14 at 17:27 +0300, Artem Bityutskiy wrote:
>   
>>>> And finally, could you please try to reproduce this problem with
>>>> nandsim:
>>>> http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_nandsim
>>>>   
>>>>         
>>>  >>> Unfortunately, I couldn't reproduce the problem with nandsim.It 
>>> works with nansim.
>>> However i couldn't test with 1GiB nandsim as it needs 1GiB ram.Tested 
>>> with 512MiB nandsim.
>>>
>>> I guess it is a could be data corruption either in platform  specific 
>>> driver or ubifs.
>>> Is there any way we can validate the platform specific nand driver ?
>>> Please let me know your views on this?
>>>
>>> Actually we are in the process of migrating from yaffs to ubifs, The 
>>> same test application works  with
>>> yaffs as well.
>>>       
>> I've created this piece of documentation for you:
>> http://www.linux-mtd.infradead.org/doc/general.html#L_mtd_tests
>>
>> Please, validate your flash driver/HW.
>>     
>
> And here is the text in case someone would review it:
>
> The MTD subsystem includes a set of tests which you may run to verify
> your flash hardware and drivers. The tests are available in the mainline
> kernels starting from kernel version 2.6.29 and they live in the
> drivers/mtd/tests directory of the linux kernel source codes. You may
> compile the tests as kernel modules by enabling them in the kernel
> configuration menu by marking: "Device Drivers" -> "Memory Technology
> Devices (MTD)" -> "MTD tests support" (or the MTD_TESTS symbol in
> the .config file).
>
> If you have a pre-2.6.29 kernel, you may find the tests here:
>
> git://git.infradead.org/users/ahunter/nand-tests.git
>
> The MTD test-suite contains the following tests:
>
>       * mtd_speedtest: measures and reports read/write/erase speed of
>         the MTD device.
>       * mtd_stresstest: performs random read/write/erase operations and
>         validates the MTD device I/O capabilities.
>       * mtd_readtest: this tests reads whole MTD device, one NAND page
>         at a time including OOB (or 512 bytes at a time in case of
>         flashes like NOR) and checks that reading works properly.
>       * mtd_pagetest: relevant only for NAND flashes, tests NAND page
>         writing and reading in different sizes and order; this test was
>         originally developed for testing the OneNAND driver, so it might
>         be a little OneNAND-oriented, but must work on any NAND flash.
>       * mtd_oobtest: relevant only for NAND flashes, tests that the OOB
>         area I/O works properly by writing data to different offsets and
>         verifying it.
>       * mtd_subpagetest: relevant only for NAND flashes, tests sub-page
>         I/O.
>       * mtd_torturetest: this test is designed to wear out flash
>         eraseblocks. It repeatedly writes and erases the same group of
>         eraseblocks until an I/O error happens, so be careful! The test
>         supports a number of options (see modinfo mtd_torturetest) which
>         allow you to set the amount of eraseblocks to torture and how
>         the torturing is done. You may limit the amount of torturing
>         cycles using the cycles_count module parameter. It may be very
>         god idea to run this test for some time and validate your flash
>         driver and HW, providing you have a spare device. For example,
>         we caught rather rare and nasty DMA issues on an OMAP2 board
>         with OneNAND flash, just by running this tests for few hours.
>
>   

  reply	other threads:[~2009-09-15  8:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-08  6:02 UBIFS Error JerinJacob
2009-09-08  7:57 ` Adrian Hunter
2009-09-08 12:16   ` JerinJacob
2009-09-10 12:01   ` JerinJacob
2009-09-10 12:13     ` Artem Bityutskiy
2009-09-10 12:53       ` JerinJacob
2009-09-10 13:46         ` Artem Bityutskiy
2009-09-10 14:22           ` JerinJacob
2009-09-11 12:18           ` JerinJacob
2009-09-14 14:27             ` Artem Bityutskiy
2009-09-14 14:29               ` Artem Bityutskiy
2009-09-15  8:28                 ` JerinJacob [this message]
2009-09-17  8:38                   ` JerinJacob
2009-09-28 11:22                     ` Artem Bityutskiy
2009-09-29  5:48                       ` JerinJacob
2009-09-30  5:37                         ` Artem Bityutskiy
2009-09-14 15:07               ` JerinJacob
2009-09-14 15:08                 ` 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=4AAF5016.2030809@maxim-ic.com \
    --to=jerin.jacob@maxim-ic.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=adrian.hunter@nokia.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).