On 25 May 2011 16:31, Benjamin Deering <[email protected]> wrote: > > I tried a kernel with MTD_DEBUG enabled, here are the messages from around > the time ubiformat fails: > > [ 599.750000] MTD_write > [ 599.810000] MTD_ioctl > [ 599.810000] MTD_write > [ 599.880000] MTD_ioctl > [ 599.890000] MTD_write > [ 599.950000] MTD_ioctl > [ 599.960000] MTD_write > [ 600.030000] MTD_ioctl > [ 600.040000] MTD_write > [ 600.110000] MTD_ioctl > [ 600.110000] nand_erase_nand: Failed erase, page 0x0000aec0 > [ 602.400000] MTD_ioctl > [ 602.400000] MTD_close > > There is no mention of the bbt in dmesg, I'll keep trying.
I had only short looks into nandwrite and the ubifs driver of the kernel. The bad block table is used and maintained by the ubifs driver only. When the driver hits on a bad block, it adds this one to the bbt, a replacement block is used. nandwrite (and I guess ubiformat too) operate on /dev/mtd devices, when they receive an error on reading or writing a block, it is simply skipped. There is no logic to deal with the bbt, at least in nandwrite. _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
