From: Richard Weinberger <richard@nod.at>
To: Stefan Agner <stefan@agner.ch>, computersforpeace@gmail.com
Cc: Bhuvanchandra DV <bhuvanchandradv@gmail.com>,
linux-mtd@lists.infradead.org
Subject: Re: UBIFS errors when file-system is full
Date: Wed, 12 Aug 2015 09:27:36 +0200 [thread overview]
Message-ID: <55CAF568.5090704@nod.at> (raw)
In-Reply-To: <e3d338cfd875b941061d5ac3da9f29c0@agner.ch>
Stefan,
Am 12.08.2015 um 09:01 schrieb Stefan Agner:
> Hi Richard,
>
> [also added Brian to the discussion, since he had a look into that
> driver before]
Good idea, maybe Brian has an idea.
> On 2015-08-07 14:37, Richard Weinberger wrote:
>> Hi!
>>
>> Am 06.08.2015 um 12:31 schrieb Bhuvanchandra DV:
>>>>> The tests ran on ubi partition after isolating it from U-Boot completly.
>>>>> Formatted the ubi partition and then boot with SD card (4.1.2 kernel fastmap enabled/disabled, fm_debug enabled).
>>>>> Please find the below log of ubi-tests:
>>>>>
>>>>> [io_paral] write_thread():222: written and read data are different
>>>> *blink*
>>>
>>> Tried to run the io_paral test multiple times seperately with few debug prints added to see what exact
>>> differences with read and write buffers, so far we could see one complete page is read twice even though
>>> it is written once. I'm now confused is the issue happen while reading or while writing. Can you give us
>>> some pointers so that we can narrow down the cause for this failure.
>>
>> The test verifies that the data has been written correctly to the block.
>> (Maybe a buffer problem in your MTD driver?)
>>
>> You can also enable UBI's IO checks.
>> i.e. echo 1 > /sys/kernel/debug/ubi/ubi0/chk_io
>>
>> It will also verify it's writes. Maybe it can give you a clue.
>
> According to Bhuvan's test, it really seems that we have an issue on
> write path (this error is reproduceable):
> root@colibri-vf:~/ubi-tests-bin# ./io_paral /dev/ubi0 2>&1 | tee
> ~/io-parl4.log
> [ 6451.223087] ubi0 error: self_check_write: self-check failed for PEB
> 843:4096, len 126976
> [ 6451.231650] ubi0: data differ at position 61440
> [ 6451.236325] ubi0: hex dump of the original buffer from 61440 to
> 126976
> [ 6451.331045] ubi0: hex dump of the read buffer from 61440 to 126976
> [ 6451.426703] CPU: 0 PID: 1182 Comm: io_paral Not tainted
> 4.1.4-00704-g2631972 #21
> [ 6451.434506] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Thanks for letting me know. :)
> This 4.1.4 with v10 of the driver applied:
> http://thread.gmane.org/gmane.linux.drivers.devicetree/130300
>
>
> I worked on the driver since quite some time, currently v10 is in
> review. With this issue in mind, I went through the driver however I
> currently can't see an issue.
>
> The error position is always page aligned, but at different pages. We
> printed the reread buffers once: It seems that one page lands on flash
> twice. My guess is that the second page doesn't get transmitted
> properly, while the new column/row gets transmitted and
> NAND_CMD_PAGEPROG executed... Hence the same buffer would be written to
> the device again.
>
> The NFC IP in Vybrid (vf610) has a higher level programming model which
> takes care of the command sequencing. Therefore some callbacks are not
> actually sending a command to the device (e.g. NAND_CMD_SEQIN) since
> this will be done one command later, on in NAND_CMD_PAGEPROG. Now, of
> course, the driver relies heavily on not being interrupted by other
> requests in between, (also not read!) but I thought that this is taken
> care of by the MTD subsystem? So for me it is a bit hard to spot the
> error since I'm always unsure whether the assumptions regarding
> locking/exclusiveness between the calls is really guaranteed...
NAND access is serialized using nand_get_device() and nand_release_device()
in nand_base.c, so serialization should be fine.
HTH,
//richard
next prev parent reply other threads:[~2015-08-12 7:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 13:55 UBIFS errors when file-system is full Bhuvanchandra DV
2015-07-13 14:09 ` Richard Weinberger
2015-07-14 4:23 ` Bhuvanchandra DV
2015-07-14 6:13 ` Richard Weinberger
2015-07-14 6:30 ` Bhuvanchandra DV
2015-07-14 6:32 ` Richard Weinberger
2015-07-14 8:29 ` Bhuvanchandra DV
2015-07-14 8:42 ` Richard Weinberger
2015-07-14 10:08 ` Bhuvanchandra DV
2015-07-14 11:06 ` Richard Weinberger
[not found] ` <55A74812.2020906@gmail.com>
2015-07-16 7:35 ` Fwd: " Bhuvanchandra DV
[not found] ` <55A74AA1.2000000@nod.at>
[not found] ` <55A7540C.3050900@nod.at>
[not found] ` <55A7592D.6010906@gmail.com>
[not found] ` <55A75A05.7040603@nod.at>
2015-07-16 7:33 ` Bhuvanchandra DV
2015-07-21 6:04 ` Bhuvanchandra DV
2015-07-21 6:14 ` Richard Weinberger
2015-07-22 7:10 ` Bhuvanchandra DV
2015-07-22 7:20 ` Richard Weinberger
2015-07-24 14:43 ` Bhuvanchandra DV
2015-07-24 16:51 ` Richard Weinberger
2015-07-31 16:47 ` Bhuvanchandra DV
2015-08-01 6:36 ` Richard Weinberger
2015-08-06 10:31 ` Bhuvanchandra DV
2015-08-07 12:37 ` Richard Weinberger
2015-08-12 7:01 ` Stefan Agner
2015-08-12 7:27 ` Richard Weinberger [this message]
2015-09-01 0:45 ` Stefan Agner
2015-09-01 1:43 ` Brian Norris
2015-09-01 2:20 ` Stefan Agner
2015-09-02 19:58 ` Stefan Agner
2015-09-02 20:13 ` Brian Norris
2015-09-02 20:41 ` Stefan Agner
2015-09-07 13:47 ` Bhuvanchandra
2015-09-11 4:03 ` Bhuvanchandra
2015-09-12 9:39 ` Richard Weinberger
2015-09-13 4:45 ` Bhuvanchandra
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=55CAF568.5090704@nod.at \
--to=richard@nod.at \
--cc=bhuvanchandradv@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=stefan@agner.ch \
/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.