Hello,

We ran into this linux kernel crash during mounting yaffs2 partition (please find full Oops file attached below)
and from the trace-back and register analysis I conclude that:

The trace-back function call chain:
get_sb_bdev ->
yaffs_internal_read_super ->
yaffs_GutsInitialise ->
yaffs_CheckpointRestore ->
yaffs_ReadCheckpointData ->
yaffs_ReadCheckpointObjects ->
yaffs_ReadCheckpointTnodes ->
yaffs_AddOrFindLevel0Tnode -> memcpy

>From the looking into yaffs_AddOrFindLevel0Tnode code it's pretty clear that the only reason for memcpy
(at the end of yaffs_AddOrFindLevel0Tnode) to crash is having both  fStruct->topLevel = 0 and fStruct->top = 0.

Looks like this problem is not reproducible easily - we saw it only ones so far and I suspect
the root cause of it (as well as few others odd problems we run into from time to time - see, for example, http://aleph1.co.uk/lurker/message/20060914.181435.951c1454.en.html) is a flash file system corruption.

Questions:
---------------

1) Can you imagine what could be the reason (other than flash fs corruption) for this Oops crash ?

2) I see that currently in our yaffs code we have defined:

#define CONFIG_YAFFS_DISABLE_CHUNK_ERASED_CHECK

means that erasure check of NAND chunks is NOT performed before
write, but I know for sure that from time to time we do encounter
not erased chunks as result of power-off during block erasure.
What could be the consequences of using not erased chunks for
yaffs_WriteChunkWithTagsToNAND ? Could it cause fs corruptions ?
problems like http://aleph1.co.uk/lurker/message/20060914.181435.951c1454.en.html ??
or this current crash ???

Thank you for any hint you can provide.

Gennady Dagman.

Gennady Dagman.