How does ubiupdatevol deals with corrupted state

Pierre Mallard mallard.pierre at gmail.com
Wed Sep 7 09:13:40 PDT 2016


Hello,

I have a question on ubiupdatevol expected behavior. Indeed, from
times to times it happens that after a call to ubiupdatevol on a
static volume, the volume is marked as corrupted by ubi driver, but
ubiupdatevol return always success.

In those case, kernel print following messages :

1970-01-01T02:42:09.660119+00:00 | kernel | - | UBI warning:
ubi_eba_read_leb: CRC error: calculated 0xa1327885, must be 0x3745d28a
1970-01-01T02:42:09.660178+00:00 | kernel | - | UBI warning:
vol_cdev_write: volume 5 on UBI device 0 is corrupted

After a few search in latest kernel master and mtd-utils git sources,
it appears that :

· A write to /dev/ubix_y… will not always lead to a returned error
from driver but rather may only mark the volume as corrupted if
failure is detected (vol_cdev_write function, when successive write
succeeded and ubi_check_volume returned 1 for ecc error)
· ubiupdatevol does not check for corrupt flag after update if write
is successful and therefore does not return an error if volume is
corrupted.

My first question is whether what happened to me, can happen : i.e.
can the volume get corrupted without a write error reported by driver
? (I would suspect therefore a problem in nand driver  - pl353 from
Xilinx for this case - )

In the eventuality where this is part of a standard “degraded”
behavior, what is the reason for not checking for corruption in
ubiupdatevol ?

Is this only a static volume problem ? i.e. any chance to encounter
same problem in dynamic volume.

Thanks a lot for your help,

Regards,



More information about the linux-mtd mailing list