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.aka...@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.aka...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot