Re: CONFIG_PREEMPT and JFFS2 oops

Paul Walmsley
2012-01-25T21:18:08Z

Hi

On Wed, 25 Jan 2012, Orjan Friberg wrote:

> With CONFIG_PREEMPT=y and hammering away on two different JFFS2 partitions on
> a NAND flash I get an oops within ~10 seconds. This is on a BeagleBoard xM
> (rev A2, with NAND).
>
> I've boiled it down to whether CONFIG_PREEMPT (bug happens) or
> CONFIG_PREEMPT_VOLUNTARY (bug doesn't happen) is selected. Of course,
> changing that affects a other things like inline spinlocking. Turning on
> CONFIG_DEBUG_SPINLOCK reveals nothing.
>
> By changing this option, I've made the bug go away in a 2.6.32 and
> 2.6.37 setup where it previously happened, and I've made it appear in a
> 2.6.39 setup where it previously didn't happen.
>
> Pointers on what to look at next are appreciated. (I've posted this on the
> mtd-utils mailing list too.) More details below.

...

> Sometimes the oops trace originates from the garbage collector,
> sometimes the result is a JFFS2 decompress error.

The problem is unlikely to be OMAP-specific, given the oops you sent.

Here are some suggestions for debugging:

- Try changing all the spin_lock() calls to spin_lock_irqsave() and all
the spin_unlock() calls to spin_unlock_irqrestore() to see if the
preemption count is being prematurely decremented

- If your oopses are consistently in the same places, add some debugging
to that code to determine which line is actually causing the oops.
Either that, or try disassembling the function to see what instruction
is causing the problem, and reference that back to the source file. The
latter is actually preferable since it is less likely to cause the
problem to mysteriously disappear. Doing this analysis should provide a
good clue as to where to look next. I personally would be rather
suspicious of that

ri->data_crc = cpu_to_je32(crc32(0, comprbuf, cdatalen));

in jffs2_write_inode_range().

- Try turning on JFFS2 debugging and seeing if you can reproduce it.
The output might provide a clue as to where the problem would be.

- Paul