Regarding UBI fastmap data CRC failure

[Ronak Desai]

Best Regards,
Ronak Desai



On Tue, Mar 28, 2017 at 8:58 AM, Ronak Desai
<ronak.desai at rockwellcollins.com> wrote:
> On Wed, Mar 22, 2017 at 5:49 PM, Richard Weinberger <richard at nod.at> wrote:
>> Ronak Desai,
>>
>> Am 21.03.2017 um 17:31 schrieb Ronak Desai:
>>> On Mon, Mar 20, 2017 at 5:56 PM, Richard Weinberger
>>> <richard.weinberger at gmail.com> wrote:
>>>> On Mon, Mar 20, 2017 at 10:47 PM, Ronak Desai
>>>> <ronak.desai at rockwellcollins.com> wrote:
>>>>> Hi All,
>>>>>
>>>>> In one of the products with MLC NAND flash, we are using UBI
>>>>> filesystem with kernel 3.12.
>>>>
>>>> MLC NAND is currently not supported.
>>>
>>> First of all, thanks for your response and your truly amazing
>>> contribution in UBI.
>>
>> Thanks. :-)
>>
>>> I know that UBIFS requires a whole lot of changes to handle "program
>>> disturb", "read distrurb" and "paired pages" problem on MLC NANDs.
>>> But, apart from this, we have makesure that we use 256 wear-leveling
>>> threshold.
>>
>> How do you handle paired pages?
>> A powercut can still damage UBI and UBIFS.
>>
> We received patch-sets from Micron for paired page issue.
>> [...]
>>
>>> That is true that our kernel is old but at this point and time it's
>>> not a viable options for us to upgrade the kernel version. And agree
>>> with your point about MLC but in months of use, we have seen this
>>> continuous fastmap failure issue only once and apart from that UBIFS
>>> works without any other issues.
>>>
>>> I see your changes on base fastmap implementation, which I am planning
>>> to backport but it will be really difficult to backport the whole UBI
>>> subsystem. So, if you can point to specific patches/changes to avoid
>>> "fastmap data CRC failure" issue then it will be a great help.
>>
>> I fear it is not that easy. Fastmap saw many fixes and improvements
>> other the time. The first version was rather buggy.
>> And we made a stupid mistake at the beginning, we did not mark fixes
>> for stable processing since Fastmap was considered
>> as experimental. That's why you can't just backport all patches that
>> have a stable tag.
>> On the other hand, backporting the whole UBI subsystem is not that
>> complicated. It has very few dependencies.
>> U-Boot folks do this on a regular basis.
>>
> So, I found out a way to reproduce and fix it. If I powercycle around
> the time when UBI performs recovery then it ends up with the CRC
> failure issue and it can not recover from it. This behavior is with
> 3.12 kernel. Then I started patching UBI with the fixes related to
> fastmap and fastmap WL, and got a state where UBI encounters the same
> problem but on subsequent boot it recovers from it.
>
> I need to perform more testing to finalize the changes though. I
> appreciate your time for answering my questions.

So, I confirm that after doing a regression with back-ported UBI
subsystem I don't see this issue anymore on kernel 3.12.

Also, I wanted to test whether the wear leveling is working correctly
or not. Is there any tests/utility which I can cross compile and run
to test these algorithms ?

>
> Thanks,
> Ronak
>
>> HTH,
>> //richard