[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unknown INCOMPAT nodetype C002 at 0196f9e0

I'm able to reproduce this, but it takes some time (its on a 50MB
partition.)  I'll try on a smaller one to reduce the amount of data
to sort throught.

I also tried the jffs2_2.4_branch and was unable to reproduce the
problem. (Not that it doesn't exist.)

              David Woodhouse <dwmw2@xxxxxxx.org>              
              2002-01-18 04:19 AM                                

To:   Chris Lesiak/Li-cor@Li-cor
cc:   jffs-dev@xxxxxxx.com
Subject:  Re: Unknown INCOMPAT nodetype C002 at 0196f9e0

clesiak@xxxxxxx.com said:
> jffs2_get_inode_nodes() is occasionally generating the message
> "Unknown INCOMPAT nodetype C002 at 0196f9e0".

> I think this could be caused by garbage collection moving the node out
> from under me again.

jffs2_get_inode_nodes() is called only from jffs2_do_read_inode(). The
garbage-collection code would have to call iget() for the inode in
question, and iget() wouldn't return until read_inode() had finished.

So there's no need for the init_MUTEX(&f-sem) at the beginning of
jffs2_do_read_inode() to be init_MUTEX_LOCKED.

> In this case, it seems as if there is no semaphore to protect the
> operation.  Is it true that the intent was to just recheck the
> obsolete flag in the low bit of the flash offset after the read of the
> node?

No, the intent was that if we know the node is obsolete (because the low
bit of flash_offset is set) then we don't bother to read it from the flash
at all.

And if it isn't marked obsolete in our own in-memory representation and we
went ahead with reading it from the flash, I'm somewhat concerned by the
fact that the node on the _flash_ says it's obsolete.

Can you take a snapshot of the offending filesystem, then do a complete
debug run, logging all the KERN_DEBUG messages and mail it all to me?


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com