On 17/05/10 18:10, Peter Barada wrote:
> On Mon, 2010-05-17 at 10:42 +0200, yaffs@piments.com wrote:
>> On 05/16/10 23:02, Charles Manning wrote:
>> > On Monday 17 May 2010 01:09:27yaffs@piments.com <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
>> >
>> >
>> >
>> Thanks Charles,
>>
>> I have checked that the .config MTD options are the same in the two
>> kernels. So, is what you're saying that this is almost certainly coming
>> from changes in the way the kernel mtd code handles oob ?
>>
>> Is this likely to be finger trouble on my part or is it to be expected
>> that the code will not be stable from one kernel release to another?
>> Specifically from 2.6.29 to 2.6.32
>>
>> The main purpose of yaffs is reduce flash wear. Mounting the mtd block
>> device is a means of testing the kernel before committing to using it.
>>
>> I will very likely erase_all and install the new fs when I commit. What
>> I don't want to do is erase it , burn the fs , find a problem , erase it
>> burn the old fs as a test cycle then start again.
>>
>> I can't allow myself to get distracted into debugging the kernel mtd
>> handlers , what I need to know is whether this a sign that something is
>> badly wrong with this jaffs on this build or whether this is to be
>> expected when trying to mount a block created by an earlier kernel.
>>
>> Are you able to comment on that?
>
> YAFFS runs just fine across kernel versions, with data burned in one
> version that is read in another kernel version, that is, if the MTD
> layout of data in NAND pages does not change. I've done this on kernel
> versions 2.6.22.18, 2.6.28-rc8, 2.6.31-rc7, 2.6.32, 2.6.34-rc5.
>
> But if in your universe, some aspect of MTD and OOB handling changed
> (OOB layout, ECC method, etc) between kernel versions, this can easily
> cause failure of YAFFS to read/write data that is understood by another
> kernel version.
>
> You will have to investigate what changed in MTD between kernel versions
> - it may be a change in the driver that does not show up as a kernel
> config choice (which may be why your perusal of .config didn't show
> anything obvious).
>
>> Thanks.
>>
Hi Peter ,
many thanks for the explanation. Now I know what to expect, I can start
looking further.
much appreciated. ;)
(text/plain)