How does ubiupdatevol deals with corrupted state

[Richard Weinberger]

Pierre,

On Wed, Sep 7, 2016 at 6:13 PM, Pierre Mallard <mallard.pierre at gmail.com> wrote:
> 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

This must not happen.

> 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 - )

Please verify your driver. i.e. run ubi tests. They are part of the mtd-utils
source package.

> 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.

With static volumes you notice because they offer data checksumming.
Maybe your driver has an issue and updating static volumes is just the
most visible symptom.

-- 
Thanks,
//richard