Re: [Yaffs] more tragedy than ancient greece

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: yaffs@piments.com
Date:  
To: yaffs
Subject: Re: [Yaffs] more tragedy than ancient greece
On 05/18/10 00:12, wrote:
> On 17/05/10 18:10, Peter Barada wrote:
>> On Mon, 2010-05-17 at 10:42 +0200, wrote:
>>> On 05/16/10 23:02, Charles Manning wrote:
>>> > On Monday 17 May 2010 01:09:
>>> <mailto:yaffs@piments.com> wrote:
>>> >> Hi,
>>> >>
>>> >> I have been using 2.6.29 patched to yaffs2 and it works fine.
>>> >>
>>> >> I am now trying to move to 2.6.32.11 , all is well except yaffs.
>>> >>
>>> >> Booting via nfs I have one fs image for *29 and another for *32
>>> >>
>>> >> Booting to *29 I can mount /dev/mntblock1 , it is clean and df shows
>>> >> correct values.
>>> >>
>>> >> # mount -t yaffs /dev/mtdblock1 /mnt/tmp
>>> >> yaffs: dev is 32505857 name is"mtdblock1"
>>> >> yaffs: passed flags""
>>> >> yaffs: Attempting MTD mount on 31.1,"mtdblock1"
>>> >> yaffs: auto selecting yaffs2
>>> >> Partially written block 513 detected
>>> >> Partially written block 513 detected
>>> >> Partially written block 513 detected
>>> >> ...
>>> >> /dev/mtdblock1 on /mnt/tmp type yaffs (rw)
>>> >> # df -h
>>> >> Filesystem Size Used Available Use% Mounted on
>>> >> /dev/root 4.1G 3.6G 319.6M 92% /
>>> >> tmpfs 64.0K 0 64.0K 0% /dev
>>> >> /dev/mtdblock1 125.0M 34.2M 90.8M 27% /mnt/tmp
>>> >>
>>> >>
>>> >>
>>> >> Booting from *32 when I try to mount /dev/mtdblock1 I get a
>>> shitload of
>>> >> tragedy.
>>> >>
>>> >> # mount -t yaffs2 /dev/mtdblock1 /tmp/mnt
>>> >> ...
>>> >> **>> Block 972 needs retiring
>>> >> **>> Block 973 needs retiring
>>> >> **>> Block 974 needs retiring
>>> >> **>> Block 975 needs retiring
>>> >> **>> Block 976 needs retiring
>>> >> **>> Block 977 needs retiring
>>> >> **>> Block 978 needs retiring
>>> >> **>> Block 979 needs retiring
>>> >> **>> Block 980 needs retiring
>>> >> **>> Block 981 needs retiring
>>> >> **>> Block 982 needs retiring
>>> >> **>> Block 983 needs retiring
>>> >> **>> Block 984 needs retiring
>>> >> **>> Block 985 needs retiring
>>> >> **>> Block 986 needs retiring
>>> >> **>> Block 987 needs retiring
>>> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
>>> >> yaffs tragedy: no more erased blocks
>>> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
>>> >> yaffs tragedy: no more erased blocks
>>> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
>>> >> yaffs_read_super: isCheckpointed 0
>>> >> ...
>>> >>
>>> >> I've checked the two .config files have the same yaffs options
>>> >>
>>> >>
>>> >> This is rather reminiscent of the case where I moved from 2.4 to 2.6
>>> >> where I had similar types of problems and had to erase_all and
>>> install a
>>> >> new fs. Since the older kernel was years old and it was a major
>>> update I
>>> >> deemed this was acceptable and cleared the whole fs. Now it seems
>>> less
>>> >> normal.
>>> >>
>>> >> Is this something I am doing wrong or is there no attempt to keep
>>> yaffs2
>>> >> stable across kernel versions, even minor updates?
>>> >>
>>> >
>>> > This is happening because yaffs is seeing write errors. If every
>>> block has
>>> > write errors and needs to be retired then eventually there are no
>>> usable
>>> > blocks.
>>> >
>>> > This is almost certainly a change in the way mtd is handling the
>>> oob data.
>>> >
>>> > What happens if you erase the flash before mounting it?
>>> >
>>> > Have a detailed look at the way mtd oob data is being handled.
>>> >
>>> > -- Charles
>>> >
>>> >
>>> >


OK, bottom line on this. Charles was entirely right his diagnosis
although it took some time to find what the underlying cause was.

Basically this hardware has two sizes of NAND in production and tables
need to be set to properly indicate size and offsets. This had been lost
somewhere in moving kernels.

The result is that the redboot partitions get mounted read only . This
gives the rather confusing erros about bad blocks and the "tragic"
consequences seen above.

As Charles said, this in fact has nothing to do with yaffs , although it
appears to be so.

Many thanks for the help in getting to the true cause.

regards.