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 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. ;)