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

[Faiz Abbas]

Hi,

On 21/03/19 12:20 PM, Faiz Abbas wrote:
> 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.
> 

Update on this:

I saw the issue in rc4 on a dra76x-evm one time but its really hard to
find out the exact steps and successive tries have failed to reproduce
it. I did setup an infinite while loop with tftp, write, read-back and
compare of boot images again and again, but that doesn't reproduce it
either after a few tens of tries. It seems some random writes and
read-backs should be able to reproduce it. Any ideas on a randomized
stress test?

Thanks,
Faiz