On 18/04/11 03:21, Charles Manning wrote:
> On Friday 15 April 2011 01:28:57 Nick Thompson wrote:
>> On 13/04/11 22:42, Charles Manning wrote:
>>> On Wednesday 13 April 2011 22:48:18 Nick Thompson wrote:
>>>> yaffs [master] snapshot from today, linux 2.6.33-rc4
>>>>
>>>> I have patched my kernel with yaffs for testing.
>>>>
>>>> I did:
>>>>
>>>> flash_eraseall /dev/mtd3
>>>> mount -t yaffs /dev/mtdblock3 /mnt/nand
>>>> cd /mnt/nand
>>>> touch test
>>>> cd ..
>>>> umount nand
>>>> mount -t yaffs /dev/mtdblock3 /mnt/nand
>>>> cd nand
>>>>
>>>> ls showed no files (except for lost+found). I turned on logging of erase
>>>> blocks (YAFFS_TRACE_ERASE) and dmesg showed the following:
>>>>
>>>> yaffs: dev is 32505859 name is "mtdblock3" rw
>>>> yaffs: passed flags ""
>>>> yaffs: yaffs: Attempting MTD mount of 31.3,"mtdblock3"
>>>> yaffs: auto selecting yaffs2
>>>> yaffs: block 2255 is bad
>>>> yaffs: block 2572 is bad
>>>> yaffs: block 2574 is bad
>>>> yaffs: block 3387 is bad
>>>> yaffs: block 3843 is bad
>>>> yaffs: block 3845 is bad
>>>> yaffs: block 4033 is bad
>>>> yaffs: yaffs_read_super: is_checkpointed 0
>>>> yaffs: dev is 32505859 name is "mtdblock3" rw
>>>> yaffs: passed flags ""
>>>> yaffs: yaffs: Attempting MTD mount of 31.3,"mtdblock3"
>>>> yaffs: auto selecting yaffs2
>>>> yaffs: block 2255 is bad
>>>> yaffs: block 2572 is bad
>>>> yaffs: block 2574 is bad
>>>> yaffs: block 3387 is bad
>>>> yaffs: block 3843 is bad
>>>> yaffs: block 3845 is bad
>>>> yaffs: block 4033 is bad
>>>> yaffs: yaffs_read_super: is_checkpointed 0
>>>> yaffs: yaffs_block_became_dirty block 1 state 8
>>>> yaffs: Erased block 1
>>>>
>>>> Obviously it didn't like the fist block, which I assumed had my file in
>>>> it, and decided to erase it.
>>>
>>> This is almost certainly due to your flash driver mangling the tags
>>> stored in oob.
>>>
>>>> What else should I log to try and figure out what is going on?
>>>
>>> Turn on some of the MTD level and verification tracing in yaffs.
>>>
>>> You might also want to add some printks to the flash driver.
>>>
>>>> jffs2 on
>>>> the same partition passes this same test, so I believe the NAND is work
>>>> okay.
>>>
>>> JFFS2 does not use oob so makes different use of the flash driver. It is
>>> possible for one fs to work and another not if a driver is broken.
>>>
>>> -- Charles
>>
>> Thanks Charles, that is useful input.
>>
>> I sprinkled printks around like confetti and couldn't find anything really
>> wrong, but I did notice the yaffs tracing showing eccres of 3 in many
>> places.
>>
>> This prompted me to check the NAND driver again, but in the end it seems
>> this is due to yaffs_UnpackTags2 running its own ECC checks, which detects
>> errors that it can't fix.
>>
>> I tuned checking off by default (CONFIG_YAFFS_DISABLE_TAGS_ECC=y) and
>> things look better now.
>>
>> Is this because the number of free bytes in my OOB is not enough?
>> I have
>> 22 free bytes starting as offset 2. I guess that the tag data fits, but
>> the ECC doesn't. sizeof(yaffs_PackedTags2TagsPart) + sizeof(yaffs_ECCOther)
>> is 28 bytes I think.
>
> Yes that is right. The default tags want 28 bytes.
>
>>
>> Maybe I'm wrong about that and it's simply not being written correctly -
>> though that would seem odd as I assume the tag data itself is okay...
>>
>> Is it safe to turn off the extra ECC? I assume without it the tag data is
>> not protected in any way. That doesn't sound very safe.
>
> It depends on whether or not your current ECC scheme provides protection for
> those tags or not.
>
> The other option is to go for a smaller implementation of yaffs_ECCOther. This
> is currently 3*u32 = 12 bytes but since only the LSB is useful this could
> actually fit in 3*u8 = 3 bytes, giving a total of 19 bytes.
(Sorry for the delay in replying - vacation, Easter, Royal Wedding, yada yada)
Changing yaffs_ECCOther to use three bytes as suggested does do the trick. The
ECC codes do now fit.
One member in the structure is already "unsigned char" but alignment issues tend
to cause it to use up 4 bytes of space until all three members are "unsigned
char".
Why are the other two members "unsigned" as standard? I image performance is
hardly effected. It seems a shame - for me at least :) - that I'd have to
maintain my own patch for this if I use YAFFS, or disable ECC - which seems
dubious at best.
[I note that TI's own MontaVista kernel tree appears to disable ECC in its
.config - the standard OOB ECC from TI doesn't protect more than just the
page data. Their latest kernels don't appear to include YAFFS]
Thanks,
Nick.
(text/plain)