SV: Jffs2 crach in 2.6.25.6.atmel.1

[David Woodhouse]

On Fri, 2008-08-15 at 18:10 +0200, Eirik Aanonsen wrote:
> 
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->nr_blocks =
> 0x0x000031
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->blocks[0] =
> 0x0xffffffff
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->blocks[1] =
> 0x0xffffffff
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->blocks[2] =
> 0x0xffffffff
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->blocks[3] =
> 0x0xffffffff
> JFFS2 error: (348) __jffs2_dbg_acct_sanity_check_nolock: c->blocks[4] =
> 0x0xffffffff

That just shouldn't happen. It doesn't matter that u-boot has the first
blocks reserved -- those aren't counted in this, which is about the
_logical_ partition. JFFS2 doesn't know that they exist at all.

Can you put a hardware watchpoint on c->blocks[0] and see when it's
getting scribbled on? Or failing that, set up a software check on every
interrupt, to BUG() if it's set to 0xffffffff.

(Assuming you only have one JFFS2 fs, you can hack jffs2 to store 'c' in
a global variable, then put a hack into the core interrupt handler code
to do something like:
	if (jffs2_c && jffs2_c->blocks &&
	    jffs2_c->blocks[0] == 0xffffffff)
		breakpoint();  // or BUG();

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation