Current mainline (3.6-rc3) UBIFS errors

[Artem Bityutskiy]

On Thu, 2012-08-23 at 11:27 +0200, David Jander wrote:
> On Thu, 23 Aug 2012 11:47:53 +0300
> Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> 
> > On Thu, 2012-08-23 at 10:39 +0200, David Jander wrote:
> > > On Thu, 23 Aug 2012 11:10:08 +0300
> > > Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> > > 
> > > > On Thu, 2012-08-23 at 09:50 +0200, David Jander wrote:
> > > > > [    4.069409] UBI warning: ubi_io_read: error -74 (ECC error) while
> > > > > reading 160 bytes from PEB 5616:87112, read only 160 bytes
> > > > 
> > > > Hi, looks like a problem with your driver. For some reasons it returns
> > > > ECC errors when reading small amount of data (160 bytes). Did you run
> > > > mtd tests - to they pass?
> > > 
> > > I thought so at first, but this error appeared on two different hardware
> > > platforms at the same time, when upgrading to latest mainline. I am coming
> > > from kernel 3.1, which worked fine on the MPC5121e. The ARM platform also
> > > worked without problems on a previous version (I think it was 3.4-something,
> > > not so sure right now). The only common piece of hardware/driver is the actual
> > > NAND flash chip on both boards (Samsung K9K8G08... SLC 8Gbit NAND), so I
> > > thought this had to be a (temporary) issue in current mainline code.
> > 
> > A change in the mtd layer probably caused this.
> > 
> > > > So UBI just tells that it cannot read, the root-cause is in the driver.
> > > 
> > > Two different drivers... same issue!?
> > 
> > Quite possible if there is a bug in mtd layer. First try to find out the
> > latest working kernel release.
> 
> Ok, sounds reasonable.
> I found kernel 3.5 works fine. Now bisecting...

If you want to check whether it is UBI/UBIFS to blame, please, pull the
ubifs-v3.5.git back-port tree and test. The back-port tree contains all
UBI/UBIFS changes which we have done after 3.5.

git://git.infradead.org/users/dedekind/ubifs-v3.5.git

http://git.infradead.org/users/dedekind/ubifs-v3.5.git

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120823/958ab3ed/attachment.sig>