[U-Boot] [BUG] cb8af8af5ba0 "fs: fat: support write with non-zero offset" fatwrite followed by fatload and then cmp fails

[Faiz Abbas]

Tom, Akashi,

On 18/03/19 7:29 AM, Tom Rini wrote:
> On Mon, Mar 18, 2019 at 10:57:37AM +0900, Akashi, Takahiro wrote:
>> On Sun, Mar 17, 2019 at 09:44:20PM -0400, Tom Rini wrote:
>>> On Mon, Mar 18, 2019 at 10:42:31AM +0900, Akashi, Takahiro wrote:
>>>> Hi Faiz,
>>>>
>>>> On Tue, Mar 12, 2019 at 02:11:08PM +0530, Faiz Abbas wrote:
>>>>> Hi Akashi,
>>>>>
>>>>> On 11/09/18 12:29 PM, Akashi, Takahiro wrote:
>>>>>> From: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>>>>>
>>>>>> The current write implementation is quite simple: remove existing clusters
>>>>>> and then allocating new ones and filling them with data. This, inevitably,
>>>>>> enforces always writing from the beginning of a file.
>>>>>>
>>>>>> As the first step to lift this restriction, fat_file_write() and
>>>>>> set_contents() are modified to accept an additional parameter, file offset
>>>>>> and further re-factored so that, in the next patch, all the necessary code
>>>>>> will be put into set_contents().
>>>>>>
>>>>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>>>>> ---
>>>>>
>>>>> My fatwrite, fatload and compare tests are failing in MMC with this
>>>>> commit. This is what I see:
>>>>>
>>>>> => fatwrite mmc 0 ${loadaddr} test 0x2000000
>>>>> 33554432 bytes written
>>>>> => fatload mmc 0 84000000 test
>>>>> 33554432 bytes read in 2149 ms (14.9 MiB/s)
>>>>> => cmp.b 82000000 84000000 0x2000000
>>>>> byte at 0x820c5000 (0x85) != byte at 0x840c5000 (0x9d)
>>>>> Total of 806912 byte(s) were the same
>>>>> =>
>>>>
>>>> I tried, but could not reproduce this issue.
>>>> (v2019.04-rc2)
>>>>
>>>> What I did was:
>>>> - On host, create a vfat file system and a random data file.
>>>>      dd of=vfat128M.img bs=1M count=128
>>>>      mkfs -t vfat vfat128M.img ; mount ...
>>>>      head -c 32m /dev/urandom > 32m.data
>>>>
>>>> - On qemu, try fatwrite
>>>>   (try 1)
>>>>   => fatload scsi 0:0 50000000 /32m.data 2000000
>>>>   33554432 bytes read in 539 ms (59.4 MiB/s)
>>>>   => fatwrite scsi 0:0 50000000 /32m_w.data 2000000
>>>>   33554432 bytes written
>>>>   => fatls scsi 0:0 /
>>>>   33554432   32m.data
>>>>   33554432   32m_w.data
>>>>
>>>>   2 file(s), 0 dir(s)
>>>>
>>>>   => fatload scsi 0:0 52000000 /32m_w.data
>>>>   33554432 bytes read in 537 ms (59.6 MiB/s)
>>>>   => cmp.b 50000000 52000000 2000000
>>>>   Total of 33554432 byte(s) were the same
>>>>
>>>>   (try 2)
>>>>   => fatwrite scsi 0:0 54000000 /32m_w2.data 2000000
>>>>   33554432 bytes written
>>>>   => fatload scsi 0:0 56000000 /32m_w2.data    
>>>>   33554432 bytes read in 537 ms (59.6 MiB/s)
>>>>   => cmp.b 54000000 56000000 2000000
>>>>   Total of 33554432 byte(s) were the same
>>>>
>>>> - I also confirmed that 32m.data and 32m_w.data are the same
>>>>   on the host.
>>>>
>>>>> Reverting this commit fixes this issue for me.
>>>>
>>>> So, first let me ask some questions:
>>>> - What is the size of your mmc memory?
It doesn't seem to be related to MMC size. It killed most of our boards
and all of them have different sized SD cards. The fat partition would
be around 100 MB on each.

>>>> - How did you format it?

Using the default ubuntu disks app.

>>>> - How many files are already there in the root directory?

Only MLO and U-boot.img

>>>
>>> Since I think there's some timezone mismatches here, can you please try
>>> your test in a loop?
>>
>> I'm afraid that I don't get your point. "in a loop"?
> 
> Yes.  The process you describe above, put it in a script and let it run
> over and over.
> 
>>> And this is likely showing up on something like
>>> am335x_evm or dra7xx_evm.  Thanks!>>
>> Do you mean that this might have board dependency?
> 
> Well, you were asking about the size of the MMC memory, so those boards
> might be a good place to look for clues that may differ from your setup.
> Thanks!
>

Unfortunately, I am unable to reproduce it now either. I tried it on
rc4, went back to offending commit and couldn't reproduce it there
either. I tried with different boards and with reformatted partitions
but it seems to have vanished. I will try out the read and write in a
loop that Tom suggested.

It would be a good idea if you could get fat filesystem on an MMC device
to reproduce it. It could be related to MMC only.

Thanks,
Faiz