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

[Tom Rini]

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?
> > > - How did you format it?
> > > - How many files are already there in the root directory?
> > 
> > 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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190317/4b3556fb/attachment.sig>