Re: Oops vanilla 2.6.10

[Estelle HAMMACHE <estelle.hammache@st.com>]

Konstantin Kletschke wrote:
> EEEEEK. jffs2_mark_node_obsolete called with NULL node

> >>EIP; c00bfed0 <jffs2_build_remove_unlinked_inode+30/ec>   <=====
> 
> >>r3; c01b1ed4 <log_wait+0/8>
> 
> Trace; c00bfea0 <jffs2_build_remove_unlinked_inode+0/ec>
> Trace; c00bfcf8 <jffs2_build_filesystem+1e4/38c>
> Trace; c00bfb14 <jffs2_build_filesystem+0/38c>

Not sure this is relevant, (and I have no way to test it right now), 
but it could be related to the obsolete node merging. You have NOR
flash haven't you ?

In jffs2_build_remove_unlinked_inode 
	raw = ic->nodes;
	while (raw != (void *)ic) {
		struct jffs2_raw_node_ref *next = raw->next_in_ino;
		D1(printk(KERN_DEBUG "obsoleting node at 0x%08x\n", ref_offset(raw)));
		jffs2_mark_node_obsolete(c, raw);
		raw = next;
	}

However if "next" is also raw->next_phys and is already obsolete 
and is the last in the next_in_ino chain, I think it may be 
freed in jffs2_mark_node_obsolete:

	/* Merge with the next node in the physical list, if there is one
	   and if it's also obsolete and if it doesn't belong to any inode */
	if (ref->next_phys && ref_obsolete(ref->next_phys) &&
	    !ref->next_phys->next_in_ino) {
		struct jffs2_raw_node_ref *n = ref->next_phys;
		
		spin_lock(&c->erase_completion_lock);

		ref->__totlen += n->__totlen;
		ref->next_phys = n->next_phys;
                if (jeb->last_node == n) jeb->last_node = ref;
		if (jeb->gc_node == n) {
			/* gc will be happy continuing gc on this node */
			jeb->gc_node=ref;
		}
		spin_unlock(&c->erase_completion_lock);

		jffs2_free_raw_node_ref(n);
	}

This would explain things... if you think it is plausible you could
try commenting out the node merging in jffs2_mark_node_obsolete.

Estelle