blkdev/dosfs/emmc issues.

[Gedare Bloom]

On Mon, Mar 13, 2017 at 9:42 AM, Tasslehoff Kjappfot
<tasskjapp at gmail.com> wrote:
> A little update on this. I found out that if I do the following, the md5sum
> is wrong the second time I check it.
>
> 1. Write upgrade files
> 2. Check MD5
> 3. Unmount
> 4. Mount
> 5. Check MD5
>
What is the return value from unmount?

> If I do not unmount/mount, the MD5 is ok, even after a reboot.
>
> With JTAG I discovered that after I have initiated an unmount, the
> bdbuf_swapout_task tries to do 3 writes into blocks inside the file where
> the MD5 check fails. If I just ignore those writes, it also works.
>
Now that is strange. It may be worth it to inspect the
bdbuf_cache.modified and bdbuf_cache.sync chains. Those are what the
swapout task processes. A guess is maybe there is a race condition
between the two lists when the sync happens, and you are getting a
couple of extra writes.

You might also like to enable RTEMS_BDBUF_TRACE at the top of bdbuf.c file.

>
>
> On Fri, Mar 10, 2017 at 4:49 PM, Tasslehoff Kjappfot <tasskjapp at gmail.com>
> wrote:
>>
>> I have some issues with rtems(4.11)/dosfs/emmc that I hope you can help me
>> with. The problem is corrupted files after a software upgrade. It goes like
>> this.
>>
>> 1. Format the eMMC. Doesn't matter if I use msdos_format, gparted or
>> something else.
>> 2. Boot the system and let the bootloader receive a ~10 file upgrade which
>> it writes to eMMC
>> 3. Compute md5sum of all the received files (open/read/compute/close). All
>> the md5sums are ok.
>> 4. "Disconnect" the eMMC with rtems_bdbuf_syncdev followed by umount.
>> (I've also tried turning off the eMMC after this.)
>> 5. Reboot the system. When I mount the eMMC again, the md5sum of the
>> biggest file has changed. It's ~4MB, and typically 10-12 bytes are wrong.
>>
>> I do not understand how the md5sum can be correct when read from the eMMC
>> before I boot, and then have changed after a reboot. Is there a chance that
>> I get data from some cache when I do open/read/close right after writing the
>> file? A lot of times the bad bytes have been at an offset of 0x50000 into
>> the file.
>>
>> I've tried playing with the different BDBUF and SWAPOUT defines, but it
>> doesn't affect the outcome.
>>
>> Any help or ideas on things to try appreciated.
>>
>> Best regards,
>> Tasslehoff
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users