[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120802165132.1bf1e5d7@spider.haslach.nod.at>
Date: Thu, 2 Aug 2012 16:51:32 +0200
From: Richard Weinberger <richard@....at>
To: artem.bityutskiy@...ux.intel.com
Cc: linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
adrian.hunter@...el.com, Heinz.Egger@...utronix.de,
thomas.wucher@...utronix.de, shmulik.ladkani@...il.com,
tglx@...utronix.de, tim.bird@...sony.com, Marius.Mazarel@...l.ro,
nyoushchenko@...sta.com
Subject: Re: UBI fastmap updates
Am Thu, 02 Aug 2012 17:29:01 +0300
schrieb Artem Bityutskiy <artem.bityutskiy@...ux.intel.com>:
> On Thu, 2012-08-02 at 16:15 +0200, Richard Weinberger wrote:
> > > If I understand correctly, it can be only because of a bug. If I
> > > am correct, could you please add a 'dump_stack()' to improve the
> > > error report?
> > >
> >
> > This can happen if all PEBs are used and fastmap is unable to find
> > (or produce) an empty one.
>
> In which situations is this possible? Could you please give an
> example?
>
Every time fastmap writes a new fastmap to the flash it tries to get a
new PEB and returns the old one (used for the old fastmap) back to the
WL sub-system.
If no free PEBs are available (E.g Volume is full or the erase worker
is too slow) ubi_wl_get_fm_peb() returns NULL and fastmap reuses the
currently used PEB.
In this situation ubi_wl_get_fm_peb() may trigger such an error message.
If think we should get rid of the message as this is not an error
condition. It's a well known execution path.
The only bad thing that happens in such a situation is that a PEB gets
reused.
BTW: Which version of fastmap are you testing?
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists