UBI/UBIFS issue: corrupt empty space => switched to read-only mode

UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Matteo Mattei]

Hi guys,

I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.

I already posted some requests to TI forum but I have no answers up to now:
http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875

The error I get is this:

UBI: attaching mtd6 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: max. sequence number: 1621513
UBI: attached mtd6 to ubi0
UBI: MTD device name: "FileSystem"
UBI: MTD device size: 847 MiB
UBI: number of good PEBs: 6769
UBI: number of bad PEBs: 7
UBI: number of corrupted PEBs: 0
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 6769
UBI: number of PEBs reserved for bad PEB handling: 134
UBI: max/mean erase counter: 2417/239
UBI: image sequence number: 0
UBI: background thread "ubi_bgt0d" started, PID 587
UBIFS: recovery needed
UBIFS error (pid 590): ubifs_scan: corrupt empty space at LEB 997:116771
UBIFS error (pid 590): ubifs_scanned_corruption: corruption at LEB 997:116771
UBIFS error (pid 590): ubifs_scan: LEB 997 scanning failed
UBIFS error (pid 590): do_commit: commit failed, error -117
UBIFS warning (pid 590): ubifs_ro_mode: switched to read-only mode, error -117
UBIFS: recovery completed
UBIFS: mounted UBI device 0, volume 0, name "ROOTFS"
UBIFS: file system size: 839819264 bytes (820136 KiB, 800 MiB, 6614 LEBs)
UBIFS: journal size: 33521664 bytes (32736 KiB, 31 MiB, 264 LEBs)
UBIFS: media format: w4/r0 (latest is w4/r0)
UBIFS: default compressor: none
UBIFS: reserved for root: 4952683 bytes (4836 KiB)

I already saw that in kernel 3.2.x a similar problem has been reported.
Investigating I saw that the error occurred during the journal commit.

Do you have any hints where to investigate further or where to apply
some changes to the sources to fix this issue?
One more question, I saw that in scan.c of UBI driver the policy to
handle corrupted blocks is to distinguish between powercuts and other
reasons.
In the latter case the block is put in corrupted list and no more
recovered. A comment in the sources says that the block is left there
for manual inspection.
However my system is unattended... do you see anything bad to add also
this kind of blocks to the erase list?


Thanks,

Matteo

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Matteo Mattei]

Matteo Mattei <matteo.mattei <at> gmail.com> writes:

> 
> Hi guys,
> 
> I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> 
> I already posted some requests to TI forum but I have no answers up to now:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> 
> The error I get is this:
> 
> UBI: attaching mtd6 to ubi0
> UBI: physical eraseblock size: 131072 bytes (128 KiB)
> UBI: logical eraseblock size: 126976 bytes
> UBI: smallest flash I/O unit: 2048
> UBI: VID header offset: 2048 (aligned 2048)
> UBI: data offset: 4096
> UBI: max. sequence number: 1621513
> UBI: attached mtd6 to ubi0
> UBI: MTD device name: "FileSystem"
> UBI: MTD device size: 847 MiB
> UBI: number of good PEBs: 6769
> UBI: number of bad PEBs: 7
> UBI: number of corrupted PEBs: 0
> UBI: max. allowed volumes: 128
> UBI: wear-leveling threshold: 4096
> UBI: number of internal volumes: 1
> UBI: number of user volumes: 1
> UBI: available PEBs: 0
> UBI: total number of reserved PEBs: 6769
> UBI: number of PEBs reserved for bad PEB handling: 134
> UBI: max/mean erase counter: 2417/239
> UBI: image sequence number: 0
> UBI: background thread "ubi_bgt0d" started, PID 587
> UBIFS: recovery needed
> UBIFS error (pid 590): ubifs_scan: corrupt empty space at LEB 997:116771
> UBIFS error (pid 590): ubifs_scanned_corruption: corruption at LEB 997:116771
> UBIFS error (pid 590): ubifs_scan: LEB 997 scanning failed
> UBIFS error (pid 590): do_commit: commit failed, error -117
> UBIFS warning (pid 590): ubifs_ro_mode: switched to read-only mode, error -117
> UBIFS: recovery completed
> UBIFS: mounted UBI device 0, volume 0, name "ROOTFS"
> UBIFS: file system size: 839819264 bytes (820136 KiB, 800 MiB, 6614 LEBs)
> UBIFS: journal size: 33521664 bytes (32736 KiB, 31 MiB, 264 LEBs)
> UBIFS: media format: w4/r0 (latest is w4/r0)
> UBIFS: default compressor: none
> UBIFS: reserved for root: 4952683 bytes (4836 KiB)
> 
> I already saw that in kernel 3.2.x a similar problem has been reported.
> Investigating I saw that the error occurred during the journal commit.
> 
> Do you have any hints where to investigate further or where to apply
> some changes to the sources to fix this issue?
> One more question, I saw that in scan.c of UBI driver the policy to
> handle corrupted blocks is to distinguish between powercuts and other
> reasons.
> In the latter case the block is put in corrupted list and no more
> recovered. A comment in the sources says that the block is left there
> for manual inspection.
> However my system is unattended... do you see anything bad to add also
> this kind of blocks to the erase list?
> 
> Thanks,
> 
> Matteo
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 



I have one more information about the problem...
Commenting the goto corrupted line in scan.c (inside ubifs) I was able
to recover a board with the previously reported error:


--- linux-2.6.32/fs/ubifs/scan.c        (revision 1892)
+++ linux-2.6.32/fs/ubifs/scan.c        (working copy)
@@ -339,7 +339,7 @@
                       if (!quiet)
                               ubifs_err("corrupt empty space at LEB %d:%d",
                                         lnum, offs);
-                       goto corrupted;
+                       //goto corrupted;
               }

       return sleb;


In this way I saw that the UBI layer has been able to recover later
the corrupted empty space.
What do you think about this workaround? Do you have a better way to do this?

Could it be an idea to mark this LEB to be erased and to search for
another LEB? However I understand that it is rather complex to do...
Has anybody an hint on this?

Thanks,

Matteo

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Mon, 2012-03-19 at 09:28 +0000, Matteo Mattei wrote:
> I have one more information about the problem...
> Commenting the goto corrupted line in scan.c (inside ubifs) I was able
> to recover a board with the previously reported error:

This is incorrect because it will also make UBIFS ignore real issues.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> Hi guys,
> 
> I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> 
> I already posted some requests to TI forum but I have no answers up to now:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875

Well, this error was reported several times. AFAIR, there are 2 possible
causes for this.

1. Your driver does not protect the empty space. Normally the driver
corrects bit-flips using ECC, but some systems do not do this for empty
space, i.e., for the flash regions which have been erased but have never
been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
it reports about corrupt empty space.

You can fix this by fixing the driver, at least this is what people seem
to do. If this is impossible to fix, you can teach UBIFS to tolerate
bit-flips in the empty space.

2. More difficult issue which no one still dares to start fixing is the
unstable bits issue. I do not have time to work on this, so I offer
everyone assistance, but no on so far started working on this, AFAIK.
Here is the description of the issue:

http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits

HTH.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Matteo Mattei]

Artem Bityutskiy <dedekind1 <at> gmail.com> writes:

> 
> On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > Hi guys,
> > 
> > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > 
> > I already posted some requests to TI forum but I have no answers up to now:
> > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> 
> Well, this error was reported several times. AFAIR, there are 2 possible
> causes for this.
> 
> 1. Your driver does not protect the empty space. Normally the driver
> corrects bit-flips using ECC, but some systems do not do this for empty
> space, i.e., for the flash regions which have been erased but have never
> been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
> it reports about corrupt empty space.
> 
> You can fix this by fixing the driver, at least this is what people seem
> to do. If this is impossible to fix, you can teach UBIFS to tolerate
> bit-flips in the empty space.
> 
> 2. More difficult issue which no one still dares to start fixing is the
> unstable bits issue. I do not have time to work on this, so I offer
> everyone assistance, but no on so far started working on this, AFAIK.
> Here is the description of the issue:
> 
> http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
> 
> HTH.
> 

Hi Aartem,
I have some updates (also a BCH fix) as reported here:
http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx

Anyway the read-only mounting persists.
I have errors also at run time (without power cuts) simply performing very 
frequent and stressful reading/writing operations (using dd and md5sum with 8 
parallel processes).

At this point I am wondering:
1- Is possibile that the "unstable bits" issue happens also during run-time 
simply reading and writing?
2- How can I do to tolerate bit-flips in the empty space?

This is the output of dmesg during heavy reading/writing operations (as 
described above):

UBIFS error (pid 2289): ubifs_scanned_corruption: corruption at LEB 6182:126342
00000000: fffffffd ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000080: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000000a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000000c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000000e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000100: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000120: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000140: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000160: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000180: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000001a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000001c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
000001e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000200: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000220: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000240: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
ffffffff  ................................
00000260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff                    ..........................
UBIFS error (pid 2289): ubifs_scan: LEB 6182 scanning failed
UBIFS warning (pid 2289): ubifs_ro_mode: switched to read-only mode, error -117
UBIFS error (pid 2289): make_reservation: cannot reserve 4144 bytes in jhead 2, 
error -117
UBIFS error (pid 2289): do_writepage: cannot write page 1392 of inode 17869, 
error -117


As you can see we read fffffffd instead of ffffffff.

Thanks for your time.

Matteo

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Matthieu CASTET]

Hi,

Matteo Mattei a écrit :
> Artem Bityutskiy <dedekind1 <at> gmail.com> writes:
> 
>> On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
>>> Hi guys,
>>>
>>> I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
>>>
>>> I already posted some requests to TI forum but I have no answers up to now:
>>> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
>> Well, this error was reported several times. AFAIR, there are 2 possible
>> causes for this.
>>
>> 1. Your driver does not protect the empty space. Normally the driver
>> corrects bit-flips using ECC, but some systems do not do this for empty
>> space, i.e., for the flash regions which have been erased but have never
>> been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
>> it reports about corrupt empty space.
>>
>> You can fix this by fixing the driver, at least this is what people seem
>> to do. If this is impossible to fix, you can teach UBIFS to tolerate
>> bit-flips in the empty space.
>>
>> 2. More difficult issue which no one still dares to start fixing is the
>> unstable bits issue. I do not have time to work on this, so I offer
>> everyone assistance, but no on so far started working on this, AFAIK.
>> Here is the description of the issue:
>>
>> http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
>>
>> HTH.
>>
> 
> Hi Aartem,
> I have some updates (also a BCH fix) as reported here:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx
I recomend you to use the bch patch that ivan post some time ago on the ML for OMAP.

The TI one has some issues (and is slow).


Matthieu

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 5619 bytes --]

On Thu, 2012-03-29 at 15:48 +0000, Matteo Mattei wrote:
> Artem Bityutskiy <dedekind1 <at> gmail.com> writes:
> 
> > 
> > On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > > Hi guys,
> > > 
> > > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > > 
> > > I already posted some requests to TI forum but I have no answers up to now:
> > > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> > 
> > Well, this error was reported several times. AFAIR, there are 2 possible
> > causes for this.
> > 
> > 1. Your driver does not protect the empty space. Normally the driver
> > corrects bit-flips using ECC, but some systems do not do this for empty
> > space, i.e., for the flash regions which have been erased but have never
> > been written. UBIFS expects to see all 0xFFs there, and if it doesn't,
> > it reports about corrupt empty space.
> > 
> > You can fix this by fixing the driver, at least this is what people seem
> > to do. If this is impossible to fix, you can teach UBIFS to tolerate
> > bit-flips in the empty space.
> > 
> > 2. More difficult issue which no one still dares to start fixing is the
> > unstable bits issue. I do not have time to work on this, so I offer
> > everyone assistance, but no on so far started working on this, AFAIK.
> > Here is the description of the issue:
> > 
> > http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits
> > 
> > HTH.
> > 
> 
> Hi Aartem,
> I have some updates (also a BCH fix) as reported here:
> http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx
> 
> Anyway the read-only mounting persists.
> I have errors also at run time (without power cuts) simply performing very 
> frequent and stressful reading/writing operations (using dd and md5sum with 8 
> parallel processes).

Does BCH in your tree protects the free space? CCing Ivan, just in case.
Preserving more than usual of the context for him.

> 
> At this point I am wondering:
> 1- Is possibile that the "unstable bits" issue happens also during run-time 
> simply reading and writing?

Not as far as I know.

> 2- How can I do to tolerate bit-flips in the empty space?

Make your ECC protect it. Or modify UBIFS and make it tolerate bit-flips
in empty space. I think in the newest kernels we export the ecc strength
in 'struct mtd_info', and it could be used when scanning the empty
space. But I am not so sure this is a good idea.

> This is the output of dmesg during heavy reading/writing operations (as 
> described above):
> 
> UBIFS error (pid 2289): ubifs_scanned_corruption: corruption at LEB 6182:126342
> 00000000: fffffffd ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000080: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000000e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000100: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000120: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000140: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000160: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000180: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001a0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001c0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 000001e0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000200: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000220: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000240: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 
> ffffffff  ................................
> 00000260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
> ff ff ff                    ..........................
> UBIFS error (pid 2289): ubifs_scan: LEB 6182 scanning failed
> UBIFS warning (pid 2289): ubifs_ro_mode: switched to read-only mode, error -117
> UBIFS error (pid 2289): make_reservation: cannot reserve 4144 bytes in jhead 2, 
> error -117
> UBIFS error (pid 2289): do_writepage: cannot write page 1392 of inode 17869, 
> error -117
> 
> 
> As you can see we read fffffffd instead of ffffffff.
> 
> Thanks for your time.


-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Ivan Djelic]

On Fri, Apr 13, 2012 at 04:20:45PM +0100, Artem Bityutskiy wrote:
> > > On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > > > Hi guys,
> > > > 
> > > > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > > > 
> > > > I already posted some requests to TI forum but I have no answers up to now:
> > > > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875

Hello Matteo,

I have been using a very similar setup (2.6.32 + OMAP3630), and I added BCH support
(8-bit correction) to the mtd omap2 driver, using the BCH library (not TI implementation).
My patch corrects bitflips on empty space (erased pages), so that UBIFS does not choke on corrupted empty space.

I posted a patch a while ago, albeit for a more recent kernel version:
http://lists.infradead.org/pipermail/linux-mtd/2011-October/038207.html
bit I did not get much feedback from TI maintainers.

If you have some trouble backporting this patch to your kernel, let me know, I may
have an old 2.6.32 version of the patch somewhere on my hdd :).

BR,
--
Ivan

> > 
> > Hi Aartem,
> > I have some updates (also a BCH fix) as reported here:
> > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx
> > 
> > Anyway the read-only mounting persists.
> > I have errors also at run time (without power cuts) simply performing very 
> > frequent and stressful reading/writing operations (using dd and md5sum with 8 
> > parallel processes).
> 
> Does BCH in your tree protects the free space? CCing Ivan, just in case.
> Preserving more than usual of the context for him.
> 
> > 
> > At this point I am wondering:
> > 1- Is possibile that the "unstable bits" issue happens also during run-time 
> > simply reading and writing?
> 
> Not as far as I know.
> 
> > 2- How can I do to tolerate bit-flips in the empty space?

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Artem Bityutskiy]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On Sat, 2012-04-14 at 14:11 +0200, Ivan Djelic wrote:
> On Fri, Apr 13, 2012 at 04:20:45PM +0100, Artem Bityutskiy wrote:
> > > > On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > > > > Hi guys,
> > > > > 
> > > > > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > > > > 
> > > > > I already posted some requests to TI forum but I have no answers up to now:
> > > > > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> 
> Hello Matteo,
> 
> I have been using a very similar setup (2.6.32 + OMAP3630), and I added BCH support
> (8-bit correction) to the mtd omap2 driver, using the BCH library (not TI implementation).
> My patch corrects bitflips on empty space (erased pages), so that UBIFS does not choke on corrupted empty space.
> 
> I posted a patch a while ago, albeit for a more recent kernel version:
> http://lists.infradead.org/pipermail/linux-mtd/2011-October/038207.html
> bit I did not get much feedback from TI maintainers.
> 
> If you have some trouble backporting this patch to your kernel, let me know, I may
> have an old 2.6.32 version of the patch somewhere on my hdd :).

If we have a "tested-by" - we can make them go in via the MTD tree. It
looks like Matthieu successfully tested them?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: UBI/UBIFS issue: corrupt empty space => switched to read-only mode

[Ivan Djelic]

On Sat, Apr 14, 2012 at 01:32:40PM +0100, Artem Bityutskiy wrote:
> On Sat, 2012-04-14 at 14:11 +0200, Ivan Djelic wrote:
> > On Fri, Apr 13, 2012 at 04:20:45PM +0100, Artem Bityutskiy wrote:
> > > > > On Fri, 2012-03-16 at 17:14 +0100, Matteo Mattei wrote:
> > > > > > Hi guys,
> > > > > > 
> > > > > > I am working hard on UBIFS to make it works on 2.6.32 and OMAP3530.
> > > > > > 
> > > > > > I already posted some requests to TI forum but I have no answers up to now:
> > > > > > http://e2e.ti.com/support/embedded/linux/f/354/t/171839.aspx#627875
> > 
> > Hello Matteo,
> > 
> > I have been using a very similar setup (2.6.32 + OMAP3630), and I added BCH support
> > (8-bit correction) to the mtd omap2 driver, using the BCH library (not TI implementation).
> > My patch corrects bitflips on empty space (erased pages), so that UBIFS does not choke on corrupted empty space.
> > 
> > I posted a patch a while ago, albeit for a more recent kernel version:
> > http://lists.infradead.org/pipermail/linux-mtd/2011-October/038207.html
> > bit I did not get much feedback from TI maintainers.
> > 
> > If you have some trouble backporting this patch to your kernel, let me know, I may
> > have an old 2.6.32 version of the patch somewhere on my hdd :).
> 
> If we have a "tested-by" - we can make them go in via the MTD tree. It
> looks like Matthieu successfully tested them?

Yes; I guess I'll need to submit a patch to linux-omap first, because OMAP GPMC related code
(needed for ecc) has been moved from the mtd driver to arch/arm/mach-omap2.
Also, I wrote the patch for 2.6.35, and I don't have much resources to run it on a recent
kernel. If Matteo or anybody interested could test it, that would be great.

BR,
--
Ivan