From mboxrd@z Thu Jan 1 00:00:00 1970 From: Faiz Abbas Date: Fri, 22 Mar 2019 14:43:01 +0530 Subject: [U-Boot] [BUG] cb8af8af5ba0 "fs: fat: support write with non-zero offset" fatwrite followed by fatload and then cmp fails In-Reply-To: <405c904f-e321-fac7-a121-5855003aea4f@ti.com> References: <20180911065922.19141-1-takahiro.akashi@linaro.org> <20180911065922.19141-10-takahiro.akashi@linaro.org> <961133c7-0d01-d227-3119-61d2875ceb3e@ti.com> <20190318014230.GA9937@linaro.org> <20190318014420.GS8732@bill-the-cat> <20190318015736.GB9937@linaro.org> <20190318015941.GT8732@bill-the-cat> <405c904f-e321-fac7-a121-5855003aea4f@ti.com> Message-ID: <907c0d0a-b56d-cbff-c5ae-5f4dee8a464a@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>>>>>> >>>>>>> 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 >>>>>>> --- >>>>>> >>>>>> 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