Hello Richard,
Am 21.05.2018 um 21:31 schrieb Richard Weinberger:
Patrice,
Am Montag, 21. Mai 2018, 16:07:41 CEST schrieb Richard Weinberger:
e->pnum = aeb->pnum; e->ec = aeb->ec; ubi->lookuptbl[e->pnum] = e;
ubi->thread_enabled = 1;This is not correct. At this point the UBI thread is not ready. I know, I know, U-Boot has no threads but some data structures might not be ready.
Let me think how to work around this properly.
The root cause seems to be that U-Boot misses this fix from Linux:
commit 1cb8f9776c7dcadc57885c6653943511d282633b Author: Richard Weinberger richard@nod.at Date: Tue Aug 11 23:27:44 2015 +0200
ubi: fastmap: Implement produce_free_peb() If fastmap requests a free PEB for a pool and UBI is busy with erasing PEBs we need to offer a function to wait for one. We can reuse produce_free_peb() from the non-fastmap WL code but with different locking semantics. Cc: stable@vger.kernel.org # 4.1.x- Reported-and-tested-by: Jörg Krause <joerg.krause@embedded.rocks> Signed-off-by: Richard Weinberger <richard@nod.atHeiko, I'm currently working on Fastmap in Linux[0]. I suggest to re-syncing with Linux if my changes go upstream, I can ping you them. :-) Fastmap gained many improvements since the last sync.
Yes, but I am currently under load, and doing a rebase is a bigger task I fear (I speculate currently to automate this task with tbot, let me think a little bit about this, if this would work, U-Boot UBI would autaomtically follow linux tree, and I immediately would see merge errors ...)
Also before a rebase can go mainline, we need deep testing. So no fast chance here for me ... sorry. If we can find commits, which fix this regression, it may makes sense to apply them before such a rebase ... ?
bye, Heiko
Thanks, //richard
[0] http://lists.infradead.org/pipermail/linux-mtd/2018-May/080965.html