[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 <email@example.com>
2002-01-18 04:19 AM
To: Chris Lesiak/Li-cor@Li-cor
Subject: Re: Unknown INCOMPAT nodetype C002 at 0196f9e0
> 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
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
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 firstname.lastname@example.org