Patrice:
We encountered this problem some years ago using a version of yaffs2 shipped with Wind River Linux 4, which WR pulled as “an import of the latest head of tree from
http://www.yaffs.net/:yaffs2-99c62e39578113a798483b5dc6c13a80737163f1”. The symptoms were the same: an entire 2k page was set to zero, clobbering one or more files in the process. This happened even though the filesystem was mounted read-only. We found it had about 1% probability of occurring per device per month, so it was difficult to observe in the QE process. (After we’d shipped a few thousand devices, not so difficult!)
The commit above is no longer around, but the Wind River import was done on 2010-03-24 so this is quite a long time ago. Looking at the logs it is obvious that Charles has done a tremendous amount of work on yaffs2 since then. We pulled in more recent yaffs2 source and rebuilt the 2.6 kernel without any other changes. It resolved the issue. We are using yaffs2 as of commit 4e188b08c5531f99f73383a85251e03a1e667b26<
http://www.aleph1.co.uk/gitweb/?p=yaffs2.git;a=commit;h=4e188b08c5531f99f73383a85251e03a1e667b26>, "Update to support Linux 3.14/3.15".
Merging the newer version of yaffs2 would be your best bet, but I see that could be difficult. If you can’t do that, my best guess is to look at the following commit for a bug fix:
http://www.yaffs.net/gitweb/?p=yaffs2.git;a=commitdiff;h=87166dff2586aa5d844c86945a80b098861b2b23
Some other references on this topic:
http://www.aleph1.co.uk/lurker/message/20141028.195012.89b6eed3.en.html
http://www.aleph1.co.uk/lurker/message/20141210.022418.0828208d.en.html
http://www.aleph1.co.uk/lurker/message/20150111.220210.44fc29fc.en.html
Note this bug is characterized by entire 2k pages being set to zero; bitflip errors can still occur when the exceed the correction capabilities of your NAND’s build-in ECC. I also do not know if it has any relevance to the yaffs1 Bettega raised.
Good luck,
Rob Calhoun
From: yaffs <
yaffs-bounces@stoneboat.aleph1.co.uk> on behalf of "
patrice.laporte@schneider-electric.com" <
patrice.laporte@schneider-electric.com>
Date: Thursday, January 5, 2017 at 8:19 AM
Subject: Re: [Yaffs] yaffs1 page_status = 0
Hi to all of you, readers, and a happy new year to all of you
I have the exact same problem, verry recently (last month) it happened twice, so let me give you some information about my situation :
1. We can't reproduced it, it happended twice, that's all we know
2. We use yaffs2, with inband tags, on a 2K page NAND flash
3. What we have is a file with a whole page of 0: actually it's an area of 2032 bytes at 0x00 in the file, so I assume tags is 16 bytes in the page on NAND.
4. We didn't dump the raw flash, unfortunatly, so I only have the two "corrupted" files, not the raw FS image for forensic
More about me and this problem:
- it happened really recently, and I jumped in the investigation this week only. I'm new on yaffs and just started reading about it (web site and code source reading), and I'm a bit confused and don't know where to start investigation.
- I'm working on old version of source code, under commercial licence, with our own adjustement/patch I presume, with interface to VxWorks : so there is no way for me to try migrating to latest yaffs version
Since I'm starting investigation, I will try to post here some result if they can be usefull, but for now I will appreciate some help to guide me: if someone can tell me where to start looking in source code, it will be verry nice.
In the same time, I will also look at the NAND driver, maybe issue is lower than the FS
Best regards and many thanks
Patrice
On 2016-05-03 14:03, Bettega Stefano wrote:
> Hi,
> we have a strange problem reading a file. After 8192 bytes there is a hole
> of 512 bytes that reads out as 0, because the page seems to be marked as
> deleted.
>
> static int yaffs_rd_data_obj(struct yaffs_obj *in, int inode_chunk, u8 * > buffer)
>
> returns the whole buffer filled with zeros as chunk seems not to be found
> in file.
>
> If we RAW read NAND, data is almost there, but in spare area we read page_status
> = 0. It seems to be marked as "delete", but how/where yaffs decide to mark
> it is as deletedRe: [Yaffs] yaffs1 page_status = 0
(text/plain)