Kiran, ----- Ursprüngliche Mail ----- > Von: "Kiran B S" <bs.kiran81@xxxxxxxxx> > An: "Richard Weinberger" <richard.weinberger@xxxxxxxxx>, "linux-mtd" <linux-mtd@xxxxxxxxxxxxxxxxxxx> > Gesendet: Freitag, 18. Oktober 2019 11:46:44 > Betreff: Re: Seeing ubifs unmap LEB error with linux 2.6.35 kernel > Hi Richard, > Also a reboot of the system recovered the ubifs filesystem. Okay. This indicates that the problem is not fatal. Initially we set the GC-Head to -1, unmapping the GC-Head is a common operation in UBIFS, maybe there is some logic bug in the replay code. Can you please give the following change a try? diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c index 69fa4ef03c53..03ce752d4d1e 100644 --- a/drivers/mtd/ubi/kapi.c +++ b/drivers/mtd/ubi/kapi.c @@ -610,8 +610,10 @@ int ubi_leb_unmap(struct ubi_volume_desc *desc, int lnum) if (desc->mode == UBI_READONLY || vol->vol_type == UBI_STATIC_VOLUME) return -EROFS; - if (lnum < 0 || lnum >= vol->reserved_pebs) + if (lnum < 0 || lnum >= vol->reserved_pebs) { + dump_stack(); return -EINVAL; + } if (vol->upd_marker) return -EBADF; Using dump_stack() we can see who tries to unmap a bad LEB entry. After 2.6.35 UBIFS was changed a lot maybe the issue got fixed and is not present in a recent kernel. Thanks, //richard ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/