Bad Blocks On JFFS2/NAND
I have experienced a problem in which a JFF2 filesystem on NAND became full. This is a root file system and constant writes to a logfile filled the filesystem. On investigation it was found that the NAND device now had hundreds of bad blocks.
I started to investigate this and found that JFFS2 was announcing
Newly-erased block contained word 0x1985e002 at offset 0x020f7e00
Messages which result in my mtd/jffs2 code marking the block bad. What I find strange is that a subsequent scan list the new block at a different 16k offset when the device erasesize is 16k, in this case 0x020f0000. Is that because my device is 128Mb and JFFS2 is using this 'virtual erase size' of 32k ?
I have observed this now on several different NAND devices and it seems to be more prominent while performing small writes.
I am currently trying to work out if the erase is not completing, or this is the wrong block or something else.
I was wondering if anyone has seen something similar
Cheers
Simon.
Quoted 7 lines · Simon Haynes
I have experienced a problem in which a JFF2 filesystem on NAND became full. This is a root file system and constant writes to a logfile filled the filesystem. On investigation it was found that the NAND device now had hundreds of bad blocks.
I started to investigate this and found that JFFS2 was announcing
Quoted 7 lines
Newly-erased block contained word
0x1985e002at offset0x020f7e00Messages which result in my mtd/jffs2 code marking the block bad. What I find strange is that a subsequent scan list the new block at a different 16k offset when the device erasesize is 16k, in this case
0x020f0000. Is that because my device is 128Mb and JFFS2 is using this 'virtual erase size' of 32k ?
Yes. The bad block code scans/marks physical blocks and JFFS2 operates on virtual ones, if the device size is big enough.
Quoted 5 lines
I have observed this now on several different NAND devices and it seems to be more prominent while performing small writes.
I am currently trying to work out if the erase is not completing, or this is the wrong block or something else.
Hmm, are you using Ready/Busy Pin or the timeout ?
tglx
Thomas,
I am using the ready pin.
Quoted 34 lines · Thomas Gleixner
Quoted 7 lines · Simon Haynes
I have experienced a problem in which a JFF2 filesystem on NAND became full. This is a root file system and constant writes to a logfile filled the filesystem. On investigation it was found that the NAND device now had hundreds of bad blocks.
I started to investigate this and found that JFFS2 was announcing
Quoted 7 lines
Newly-erased block contained word
0x1985e002at offset0x020f7e00Messages which result in my mtd/jffs2 code marking the block bad. What I find strange is that a subsequent scan list the new block at a different 16k offset when the device erasesize is 16k, in this case
0x020f0000. Is that because my device is 128Mb and JFFS2 is using this 'virtual erase size' of 32k ?Yes. The bad block code scans/marks physical blocks and JFFS2 operates on virtual ones, if the device size is big enough.
Quoted 5 lines
I have observed this now on several different NAND devices and it seems to be more prominent while performing small writes.
I am currently trying to work out if the erase is not completing, or this is the wrong block or something else.
Hmm, are you using Ready/Busy Pin or the timeout ?
tglx
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 3 lines · Simon Haynes
Thomas,
I am using the ready pin.
Hmm, the strange thing is, that it does not complain about a failed erase. It complaines, when checking if the chip is really erased.
Can you try the hack below, which invalidates the page cache unconditionally on erase ?
tglx
RCS file: /home/cvs/mtd/drivers/mtd/nand/nand_base.c,v retrieving revision 1.121
nand_base.c 19 Oct 2004 15:09:35 -0000 renamed from nand_base.c 6 Oct 2004 19:53:11 -0000 1.121 +0 -0
@@ -2091,8 +2091,7 @@ /* Invalidate the page cache, if we erase the block
which contains
the current cached page */
- if (page <= this->pagebuf && this->pagebuf < (page +pages_per_block))
- this->pagebuf = -1;
+ this->pagebuf = -1;
this->erase_cmd (mtd, page & this->pagemask);
I am using an old mtd layer which has nand.c and not nand_base.c. I have hacked this accordingly and I will see if I can produce the same problem.
I did try to update my kernel but patchin.sh failed and I had to hack some header files to get a kernel. This kernel crashed in a couple of different places when writing to my SSFDC partition. I guess things have changed here again ?
Cheers
Simon.
Quoted 36 lines · Thomas Gleixner
Quoted 3 lines · Simon Haynes
Thomas,
I am using the ready pin.
Hmm, the strange thing is, that it does not complain about a failed erase. It complaines, when checking if the chip is really erased.
Can you try the hack below, which invalidates the page cachen unconditionally on erase ?
tglx
RCS file:
/home/cvs/mtd/drivers/mtd/nand/nand_base.c,vretrieving revision 1.121
diff -u -r1.121nand_base.cnand_base.c 19 Oct 2004 15:09:35 -0000 renamed from nand_base.c 6 Oct 2004 19:53:11 -0000 1.121 +0
-0@@ -2091,8 +2091,7 @@ /* Invalidate the page cache, if we erase the blockwhich contains
the current cached page */
- if (page <=this->pagebuf&&this->pagebuf< (page +pages_per_block))nand_base.c 19 Oct 2004 15:09:35 -0000 renamed from nand_base.c 6 Oct 2004 19:53:11 -0000 1.121 +1
-1- this->pagebuf = -1; + this->pagebuf = -1; this->erase_cmd (mtd, page & this->pagemask);______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 25 lines · --- Thomas Gleixner
Quoted 8 lines · Simon Haynes
I have experienced a problem in which a JFF2 filesystem on NAND became full.
This is a root file system and constant writes to a logfile filled the filesystem. On investigation it was found that the NAND device now had hundreds of bad blocks.I started to investigate this and found that JFFS2 was announcing
Quoted 8 lines
Newly-erased block contained word
0x1985e002at offset0x020f7e00Messages which result in my mtd/jffs2 code marking the block bad. What I find strange is that a subsequent scan list the new block at a different 16k offset when the device erasesize is 16k, in this case
0x020f0000.
Is that because my device is 128Mb and JFFS2 is using this 'virtual erase size' of 32k ?Yes. The bad block code scans/marks physical blocks and JFFS2 operates
on virtual ones, if the device size is big enough.Quoted 3 lines
I have observed this now on several different NAND devices and it seems to be more prominent while performing small writes.
Quoted 7 lines
Quoted 2 lines
I am currently trying to work out if the erase is not completing, or this is the wrong block or something else.
Hmm, are you using Ready/Busy Pin or the timeout ?
tglx
Hi guys. This topic has given me a little bit of concern. Could you try to answer a few questions for me?
1. Do you know what usually causes the "Newly-erased block contained
word "... error?
Is it caused by a interrupted (or otherwise failed) erase? Would power-fail cause this?
2. Would this cause good blocks to be incorrectly [and permanently] marked as bad?
I think I may have seen something similar on my system. I'm considering writing a test to see if this is a problem for me, but I'd like to learn more about this also.
Thanks,
Mike
Quoted 4 lines · Michael Moedt
1. Do you know what usually causes the "Newly-erased block contained
word "... error?
Is it caused by a interrupted (or otherwise failed) erase? Would power-fail cause this?
It's caused by a failed erase. If the chip interface is correct then it is usually a problem of a bad page/block. If not (e.g. wrong timing) it might return too early from an erase.
Quoted 2 lines
2. Would this cause good blocks to be incorrectly [and permanently] marked as bad?
Only if failes 5 times after mount. The counter is reset with each mount.
Quoted 4 lines
I think I may have seen something similar on my system. I'm considering writing a test to see if this is a problem for me, but I'd like to learn more about this also.
Which version of the mtd/nand code ?
There was a problem with the page cache, which was not invalidated on erase some time ago, but its fixed.
tglx
This 5 error business is only if you have relatively new code. Old code generates an incorrect and permanent bad block after 1 failure. I am testing the suggestion by Thomas that this is a page cache problem by always marking an erase page as invalid. No errors as yet but I will keep you posted.
Cheers
Simon.
Quoted 32 lines · Thomas Gleixner
Quoted 4 lines · Michael Moedt
1. Do you know what usually causes the "Newly-erased block contained
word "... error?
Is it caused by a interrupted (or otherwise failed) erase? Would power-fail cause this?It's caused by a failed erase. If the chip interface is correct then it is usually a problem of a bad page/block. If not (e.g. wrong timing) it might return too early from an erase.
Quoted 2 lines
2. Would this cause good blocks to be incorrectly [and permanently] marked as bad?
Only if failes 5 times after mount. The counter is reset with each mount.
Quoted 3 lines
I think I may have seen something similar on my system. I'm considering writing a test to see if this is a problem for me, but I'd like to learn more about this also.
Which version of the mtd/nand code ?
There was a problem with the page cache, which was not invalidated on erase some time ago, but its fixed.
tglx
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 4 lines · Simon Haynes
This 5 error business is only if you have relatively new code. Old code generates an incorrect and permanent bad block after 1 failure. I am testing the suggestion by Thomas that this is a page cache problem by always marking an erase page as invalid. No errors as yet but I will keep you posted.
A cvs history search should reveal the changes to the nr errors thing and to the page cache fixes. So you can verify against your particular version.
tglx