[PATCH v3 0/6] UBI: add max_beb_per1024 parameter / ioctl

[Artem Bityutskiy]

On Fri, 2012-08-31 at 16:46 +0200, Richard Genoud wrote:
> BUT, I ran into a bug, I don't know if it's my kernel (as I've got
> quite a lot of patches ahead of 3.6 to get my board run), but it's
> kind of nasty.

What is your kernel? Why don't you just pull the corresponding ubifs
backport tree?

> It's not related to this patch serie, I could trigger it with a
> 3.6-rc1 kernel (and my board-patches).
> I get some memory crashing when I do :
> flash_erase /dev/mtd2 0 160 (it's a whole mtd partition)
> ubiattach -m 2

Would you please be able to reproduce this with linux-ubi tree and also
send be the full oops?

> After that, I can have a OOPS right away, but sometimes not.
> but if I run someting (top for exemple) I get an oops then.
> So, the memory is beeing corrupted somewhere, but I couldn't find out
> exactly where.

If you could somehow reproduce this with nandsim, it would make it easy
for me to find the bug.

> But I found that if I comment out the lines :
> diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
> --- a/drivers/mtd/ubi/vtbl.c
> +++ b/drivers/mtd/ubi/vtbl.c
> @@ -346,8 +346,8 @@ retry:
>          */
>         err = ubi_scan_add_used(ubi, si, new_seb->pnum, new_seb->ec,
>                                 vid_hdr, 0);

We renamed all scan functions recently, so AFAICS you are not using the
latest UBI code-base. How about picking the latest back-port tree?

> +//     kfree(new_seb);
> +//     ubi_free_vid_hdr(ubi, vid_hdr);

This is strange, I think these 2 frees are all-right, I think the
root-cause is somewhere else.


> Does someone can reproduce that ?

It is difficult to say because you did not send the full oops.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120903/074900bd/attachment.sig>