On 01/26/2012 11:15 AM, Orjan Friberg wrote:
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().
That is indeed the place where crc32 is called from . I'll see it I can
track the use of comprbuf.
Ok, so comprbuf comes from jffs2_compress and becomes NULL for some
reason (hence the oops).
Initially I had CMODE_FAVOUR_LZO. With that, things only worked with
PREEMPT_NONE. However, when changing to CMODE_PRIORITY or CMODE_NONE
things do seem to work *with* PREEMPT.
For what it's worth (with PREEMPT on):
CMODE_FAVOUR_LZO with LZO disabled oopses.
CMODE_FAVOUR_LZO with only ZLIB enabled oopses.
CMODE_FAVOUR_LZO with ZLIB/LZO/RTIME/RUBIN disabled does not oops.
Thus, the bug seems to be in the *selection* of compression algorithm
(when there is at least one algoritm in the list), rather than in the
specific compression algorithms themselves.
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
