Are there UBI layout changes between 2.6.35 and 2.6.36?

Are there UBI layout changes between 2.6.35 and 2.6.36?

[Charles Manning]

Folk

I have been helping some people get an omap3 overo-based system going. 
Everything is working fine using 2.6.35 and software ECC, but when I changed 
I change to 2.6.36 and hwecc things stop working. I get the following 
problem, and obviously no boot :-(.

UBI: attaching mtd7 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI: corrupted PEBs will be formatted
UBI: max. sequence number:       0
UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
UBI error: process_lvol: both volume tables are corrupted
UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
UBI error: ubi_init: cannot attach mtd7

I don't think this is just a straight forward software/hardware ECC issue I 
don't get the ECC error reports I would get if I load the NAND using software 
ECC.

OK, the background...

The roofts is created by mkfs.ubifs, then ubinized, then programmed via u-boot 
using hw or sw ecc as appropriate.

The following are used to create the image:

ubinize.cmd is
[rootfs-volume]
mode=ubi
image=ubifs.tmp
vol_name=root
vol_size=20MiB
vol_id=0
EOF

mkfs.ubifs  -m 2048 -e 126KiB -c 1000 -r .  $tmp_dir/ubifs.tmp	
ubinize -o $out_file -p 128KiB -s 512 -m 2048 ubinize.cmd

Has something changed between 2.6.35 and 2.6.36 that will mess up the way the 
volumes are managed?

Thanks

Charles

Re: Are there UBI layout changes between 2.6.35 and 2.6.36?

[Artem Bityutskiy]

On Thu, 2010-11-18 at 12:44 +1300, Charles Manning wrote:
> Folk
> 
> I have been helping some people get an omap3 overo-based system going. 
> Everything is working fine using 2.6.35 and software ECC, but when I changed 
> I change to 2.6.36 and hwecc things stop working. I get the following 
> problem, and obviously no boot :-(.

Hmm, should not be, at least not intentional. Could you please try to
bisect - there are not so many UBI changes so you can probably find the
offending one.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

Re: Are there UBI layout changes between 2.6.35 and 2.6.36?

[Artem Bityutskiy]

On Thu, 2010-11-18 at 10:22 +0200, Artem Bityutskiy wrote:
> On Thu, 2010-11-18 at 12:44 +1300, Charles Manning wrote:
> > Folk
> > 
> > I have been helping some people get an omap3 overo-based system going. 
> > Everything is working fine using 2.6.35 and software ECC, but when I changed 
> > I change to 2.6.36 and hwecc things stop working. I get the following 
> > problem, and obviously no boot :-(.
> 
> Hmm, should not be, at least not intentional. Could you please try to
> bisect - there are not so many UBI changes so you can probably find the
> offending one.

And in fact, you can even revert all UBI changes which happened after
2.6.35 and try it.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

RE: Are there UBI layout changes between 2.6.35 and 2.6.36?

[Jon Povey]

linux-mtd-bounces@lists.infradead.org wrote:
> Folk
>
> I have been helping some people get an omap3 overo-based system going.
> Everything is working fine using 2.6.35 and software ECC, but
> when I changed
> I change to 2.6.36 and hwecc things stop working. I get the following
> problem, and obviously no boot :-(.
>
> UBI: attaching mtd7 to ubi0
> UBI: physical eraseblock size:   131072 bytes (128 KiB)
> UBI: logical eraseblock size:    129024 bytes
> UBI: smallest flash I/O unit:    2048
> UBI: sub-page size:              512
> UBI: VID header offset:          512 (aligned 512)
> UBI: data offset:                2048
> UBI: corrupted PEBs will be formatted
> UBI: max. sequence number:       0
> UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
> UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
> UBI error: process_lvol: both volume tables are corrupted
> UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
> UBI error: ubi_init: cannot attach mtd7

...

> mkfs.ubifs  -m 2048 -e 126KiB -c 1000 -r .  $tmp_dir/ubifs.tmp
> ubinize -o $out_file -p 128KiB -s 512 -m 2048 ubinize.cmd
>
> Has something changed between 2.6.35 and 2.6.36 that will
> mess up the way the
> volumes are managed?

A couple of months ago there was a bad patch to mtd.utils that
caused mkfs.ubifs to generate bogus CRCs. That cause similar
symptoms for me. It was fixed before 2.6.36 came out of -rc.

Did you update your mtd.utils as well as the kernel?

--
Jon Povey
jon.povey@racelogic.co.uk

Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .

The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network

Re: Are there UBI layout changes between 2.6.35 and 2.6.36?

[Charles Manning]

On Thursday 18 November 2010 22:41:55 Jon Povey wrote:
> linux-mtd-bounces@lists.infradead.org wrote:
> > Folk
> >
> > I have been helping some people get an omap3 overo-based system going.
> > Everything is working fine using 2.6.35 and software ECC, but
> > when I changed
> > I change to 2.6.36 and hwecc things stop working. I get the following
> > problem, and obviously no boot :-(.
> >
> > UBI: attaching mtd7 to ubi0
> > UBI: physical eraseblock size:   131072 bytes (128 KiB)
> > UBI: logical eraseblock size:    129024 bytes
> > UBI: smallest flash I/O unit:    2048
> > UBI: sub-page size:              512
> > UBI: VID header offset:          512 (aligned 512)
> > UBI: data offset:                2048
> > UBI: corrupted PEBs will be formatted
> > UBI: max. sequence number:       0
> > UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
> > UBI error: vtbl_check: bad CRC at record 0: 0xc4ef3d92, not 0x639e7026
> > UBI error: process_lvol: both volume tables are corrupted
> > UBI error: ubi_attach_mtd_dev: failed to attach by scanning, error -22
> > UBI error: ubi_init: cannot attach mtd7
>
> ...
>
> > mkfs.ubifs  -m 2048 -e 126KiB -c 1000 -r .  $tmp_dir/ubifs.tmp
> > ubinize -o $out_file -p 128KiB -s 512 -m 2048 ubinize.cmd
> >
> > Has something changed between 2.6.35 and 2.6.36 that will
> > mess up the way the
> > volumes are managed?
>
> A couple of months ago there was a bad patch to mtd.utils that
> caused mkfs.ubifs to generate bogus CRCs. That cause similar
> symptoms for me. It was fixed before 2.6.36 came out of -rc.
>
> Did you update your mtd.utils as well as the kernel?
>

I too stumbled across that bug.
I am using the latest utils from git with both .35 and .36 so that should not 
be the problem unless there was a volume format change.

I shall investigate further.

Thanks

Charles