ubi_eba_init_scan: cannot reserve enough PEBs

[Artem Bityutskiy]

On Tue, 2010-09-07 at 11:59 -0400, Matthew L. Creech wrote:
> On Mon, Sep 6, 2010 at 5:17 AM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> >
> > The other idea which would definitely help is to create a debugging
> > patch which will track all erasures of PEBs and store them somewhere. I
> > do not know which tracing debugging tools you have, if you have some
> > fast tracing you can just send this info via your tracing interface. But
> > if you don't, you can use other flash or another partition on your flash
> > and store the info.
> >
> ...
> 
> This makes sense, however I'm not sure of a good way to store this
> info.  I don't have any hardware debugging tools (BDI, etc.) though I
> could probably get my hands on one if you think it would help.
> Creating another flash partition and saving data there could work,
> although I'm not familiar with how to do that safely/cleanly from
> within the kernel (I could give it a try though).

Well, MTD API provides all basic operations. But I guess this is more
complex, so I'd leave this as a last resort method.

> The brute-force method would be to just dump all of this info out to
> the serial console,

Serial is too slow. If this bug is about race conditions, serial will
make it unreproducible. And this will slow down stuff too much, so you'd
run the same amount of operations tens time slower.

Take a look at the netconsole - using ethernet will be faster. It is
really easy to setup - just do not forget to switch off/configure
iptables. See Documentation/networking/netconsole.txt

>  and I'll leave a minicom session running on a PC
> to capture everything that happens.  I can't be certain how long it
> would take to get a freshly-formatted device into this state, but the
> quantity of output isn't a problem if I'm capturing to a PC.

Yeah, s/minicom/netconsole/, and capture the stuff in a file. This will
makes stuff simpler, at least the 'dump_stack()' issue I told about will
go away.

> I'll probably have time to set this test up in the next few days, but
> it may be weeks until the test device goes bad (if it ever goes bad at
> all).  As far as what code should be tested, do you want me to just
> pull a copy of the latest ubifs-2.6 tree?

This is probably not so important. Use the ubifs you have, but I'd like
to also see it. And send the debugging patch to me for reveiw to
comments (you'll need to prepare).

>   Or apply these patches to
> something more stable?

I think the ubifs base where you already saw the issue will be the best.

> Thanks for your help Artem!

NP, feel free to ask questions.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)