UBIFS partition on NOR flash not mountable after power cut test

On Thu, 02 Dec 2010 14:18:45 +0200
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> 
> But this looks exactly like you have 64-bit write-buffer, but UBIFS
> c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> force 8-bytes write-buffer.

This looks exactly like I have a 16 byte write buffer. The first
16 bytes of the common header node have been written correctly but
the remaining 8 bytes of the common header and then the 8 bytes of
the data are corrupt.
> 
> Are you sure you did not miss your NOR write-buffer hacks?

I'm sure that the kernel running this test uses the modification in
the CFI code as follows:
bigger buffer. I'll check the actual size used in the CFI driver
at runtime.

Thanks,
Anatolij

On Thu, 2010-12-02 at 14:23 +0100, Anatolij Gustschin wrote:
> On Thu, 02 Dec 2010 14:18:45 +0200
> Artem Bityutskiy <dedekind1@gmail.com> wrote:
> 
> > On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> > 
> > But this looks exactly like you have 64-bit write-buffer, but UBIFS
> > c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> > force 8-bytes write-buffer.
> 
> This looks exactly like I have a 16 byte write buffer. The first
> 16 bytes of the common header node have been written correctly but
> the remaining 8 bytes of the common header and then the 8 bytes of
> the data are corrupt.
> > 
> > Are you sure you did not miss your NOR write-buffer hacks?
> 
> I'm sure that the kernel running this test uses the modification in
> the CFI code as follows:
> diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
> index e63e674..9eb47b8 100644
> --- a/drivers/mtd/chips/cfi_probe.c
> +++ b/drivers/mtd/chips/cfi_probe.c
> @@ -213,6 +213,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
>         cfi->cfiq->InterfaceDesc = le16_to_cpu(cfi->cfiq->InterfaceDesc);
>         cfi->cfiq->MaxBufWriteSize = le16_to_cpu(cfi->cfiq->MaxBufWriteSize);
>  
> +       /*printk("NOTE: change CFI MaxBufWriteSize from 2^%d to 2^%d\n",*/
> +       /*cfi->cfiq->MaxBufWriteSize, 3);*/
> +       if (cfi->cfiq->MaxBufWriteSize) {
> +               cfi->cfiq->MaxBufWriteSize = 3;
> +       }
> +
> 
> But I'm not sure whether the CFI driver is really using 8 byte
> write buffer since the error pattern indicates the usage of a
> bigger buffer. I'll check the actual size used in the CFI driver
> at runtime.

Can you instead make mtd->writesize to be 64? This is much closer to the
"right thing to do" :-)

On Thu, 02 Dec 2010 15:35:51 +0200
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> On Thu, 2010-12-02 at 14:23 +0100, Anatolij Gustschin wrote:
> > On Thu, 02 Dec 2010 14:18:45 +0200
> > Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > 
> > > On Thu, 2010-12-02 at 10:57 +0100, Anatolij Gustschin wrote:
> > > > UBIFS DBG (pid 1290): no_more_nodes: unexpected bad common header at 37:157472
> > > > UBIFS error (pid 1290): ubifs_recover_leb: bad node
> > > > UBIFS error (pid 1290): ubifs_scanned_corruption: corruption at LEB 37:157472
> > > > UBIFS error (pid 1290): ubifs_scanned_corruption: first 8192 bytes from LEB 37:157472
> > > > 00000000: 31181006 270758c8 0c331500 00000000 ffffffff ffffffff ff4fffff f3428020  1...'.X..3...............O...B. 
> > > 
> > > But this looks exactly like you have 64-bit write-buffer, but UBIFS
> > > c->min_io_unit is not 64, but it should be 64. Or you need a NOR hack to
> > > force 8-bytes write-buffer.
> > 
> > This looks exactly like I have a 16 byte write buffer. The first
> > 16 bytes of the common header node have been written correctly but
> > the remaining 8 bytes of the common header and then the 8 bytes of
> > the data are corrupt.
> > > 
> > > Are you sure you did not miss your NOR write-buffer hacks?
> > 
> > I'm sure that the kernel running this test uses the modification in
> > the CFI code as follows:
> > diff --git a/drivers/mtd/chips/cfi_probe.c b/drivers/mtd/chips/cfi_probe.c
> > index e63e674..9eb47b8 100644
> > --- a/drivers/mtd/chips/cfi_probe.c
> > +++ b/drivers/mtd/chips/cfi_probe.c
> > @@ -213,6 +213,12 @@ static int __xipram cfi_chip_setup(struct map_info *map,
> >         cfi->cfiq->InterfaceDesc = le16_to_cpu(cfi->cfiq->InterfaceDesc);
> >         cfi->cfiq->MaxBufWriteSize = le16_to_cpu(cfi->cfiq->MaxBufWriteSize);
> >  
> > +       /*printk("NOTE: change CFI MaxBufWriteSize from 2^%d to 2^%d\n",*/
> > +       /*cfi->cfiq->MaxBufWriteSize, 3);*/
> > +       if (cfi->cfiq->MaxBufWriteSize) {
> > +               cfi->cfiq->MaxBufWriteSize = 3;
> > +       }
> > +
> > 
> > But I'm not sure whether the CFI driver is really using 8 byte
> > write buffer since the error pattern indicates the usage of a
> > bigger buffer. I'll check the actual size used in the CFI driver
> > at runtime.
> 
> Can you instead make mtd->writesize to be 64? This is much closer to the
> "right thing to do" :-)

Yes. But I also must ensure that the buffer size configured in
cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
is not the case, it seems. If this is true, then I'll still run
into the similar trouble even when using 64 for max_io_size in UBI.

Thanks,
Anatolij

On Thu, 2010-12-02 at 14:50 +0100, Anatolij Gustschin wrote:
> > Can you instead make mtd->writesize to be 64? This is much closer to the
> > "right thing to do" :-)
> 
> Yes. But I also must ensure that the buffer size configured in
> cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
> is not the case, it seems. If this is true, then I'll still run
> into the similar trouble even when using 64 for max_io_size in UBI.

Err, no, I think if the UBI/UBIFS min_io_size is greater than the real
write size, it should be fine for UBI/UBIFS. UBIFS should not get upset
if min_io_size is 64, but real write size is 8 or 16 or 32, or even 1
byte, I think.

On Thu, 02 Dec 2010 15:57:56 +0200
Artem Bityutskiy <dedekind1@gmail.com> wrote:

> On Thu, 2010-12-02 at 14:50 +0100, Anatolij Gustschin wrote:
> > > Can you instead make mtd->writesize to be 64? This is much closer to the
> > > "right thing to do" :-)
> > 
> > Yes. But I also must ensure that the buffer size configured in
> > cfi->cfiq->MaxBufWriteSize is actually used by the driver. This
> > is not the case, it seems. If this is true, then I'll still run
> > into the similar trouble even when using 64 for max_io_size in UBI.
> 
> Err, no, I think if the UBI/UBIFS min_io_size is greater than the real
> write size, it should be fine for UBI/UBIFS. UBIFS should not get upset
> if min_io_size is 64, but real write size is 8 or 16 or 32, or even 1
> byte, I think.

Yes, this is my understanding, too. But I'll try to explain what I
meant in the previous email:
When I drop the 8 byte buffer hack in the CFI and set mtd->writesize
to 64, but the CFI driver is really using a multiple of the value
configured in cfi->cfiq->MaxBufWriteSize, then I'll run into the
similar trouble since the driver will probably use a n * 64 buffer,
where n > 1.

But I understand what you meant: I should just set mtd->writesize to
64 and continue to test with my hack for 8 Byte in the CFI driver.

Thanks,
Anatolij