Re: UBI leb_write_unlock NULL pointer Oops (continuation)

[Richard Weinberger <richard@nod.at>]

Am 12.02.2014 19:21, schrieb Bill Pringlemeir:
> 
> On 12 Feb 2014, bpringlemeir@nbsps.com wrote:
> 
>> We have 'IRQs off', which makes sense for __up_write.  Trying
>> 'ftrace_dump_on_oops' as Richard suggests would be helpful to find out
>> what went on before.  It might also make sense to dump some
>> 'rwsem_waiter' nodes on the error?  It looks like '__up_write' might
>> normally have an empty list?  Certainly an non-empty 'rwsem_waiter' is
>> going to trigger the condition more often?  I guess I can look to see
>> what might cause this, even if I can not reproduce it.  The
>> 'preemp_count' has been two every time you have this; is that true?
> 
> Wouldn't a smaller MTD trigger the condition more often?  It looks like
> the locking is done per erase block and several files in the same erase
> block with simultaneous reading/writing will trigger this kind of
> effect?
> 
> Does that sound right Richard?  Will it matter if I use a fixed or
> dynamic volume size?  Can I make a small UBI/UbiFS MTD partition and use
> that for testing?  My dynamic partition is about 200MB big.  Usually we
> never come near filling it, so there is lots of opportunity to use other
> erase blocks.

Yeah, I had the same idea and setup a MTD using nandsim.
So far I was unable to trigger the issue.

Let's wait for more results from Thorsten.

Thanks,
//richard