From: Stefan Agner <stefan@agner.ch>
To: Richard Weinberger <richard@nod.at>, 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:01:43 +0200 [thread overview]
Message-ID: <e3d338cfd875b941061d5ac3da9f29c0@agner.ch> (raw)
In-Reply-To: <55C4A695.7060608@nod.at>
Hi Richard,
[also added Brian to the discussion, since he had a look into that
driver before]
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)
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...
--
Stefan
next prev parent reply other threads:[~2015-08-12 7:02 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 [this message]
2015-08-12 7:27 ` Richard Weinberger
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=e3d338cfd875b941061d5ac3da9f29c0@agner.ch \
--to=stefan@agner.ch \
--cc=bhuvanchandradv@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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.