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.