I've noticed that nobody seems to be overly concerned about this data error that I reported back in July 2008. For those on the list that have had microSD problems, the links below might be worth looking into:
Since posting the initial email, I switched to the buildroot configuration and upgraded the kernel to 2.6.24 and the error count went way down (~5% of all 'large' file copies had the error). Basically, I had decided to compute md5sums before and after the copy. If an error occurred, I repeated the copy. Once, the file system on the microSD card got corrupted and I had to reformat the card.
When I heard about the problem described by Cliff Brake in the link above, I set up a test fixture:
Verdex XL6P, console-vx, netmicrosd, SanDisk USB thumbdrive (4 GB), and a SanDisk microSD (8 GB)
For my test I copy a 600 + MB file from the USB thumbdrive to the microSD card, sync the image to insure all data is written to flash, and then compute an md5sum of the file on the microSD card. I compare the new md5sum to the known md5sum of the file taking note of any differences. I then delete the file from the microSD card and re-sync. Then the process gets repeated ...
With the non-patched 2.6.24 kernel I encountered 15 errors in 281 copies. (I have no way of knowing if there was more than one dma buffer error in the copy).
With the PATCHED 2.6.24 kernel I encountered 0 errors in 750 copies.
I have implemented the modification in my project.
BTW, the arm link above references a Marvel Errata #91, the latest Specification Update that I can find (Intel) has Errata #88. Can anyone confirm if this problem is known to Marvel? Does the problem exist with the processor used on the Verdex Pro?
P.S. I didn't mention in my original email, but the problem occurred with every file system that I used on the microSD card, not just FAT32.
When I write a large file ( > 350 MB ) to a microSD card, I almost always get one or more corrupted 4KB blocks of data in the file. The file size is correct but an md5sum of the new file does not match the original. Using 'cmp' I see where the data looks shifted by one byte for about 4 KB then the data is correct again. The audio and video files I initially wrote did not seem corrupted. I didn't see the error until I copied a tarball image and something 'important' got corrupted.
My setup is a Verdex XM4, console-vx, and netmicrosd. I first noticed the problem with pre-built 308M versions of u-boot, uimage (2.6.21), and rootfs (basic). I have since loaded the pre-built images of 318M versions of each, trying both glibc and uclibc combinations of the kernel and fs. (The pre-built kernel images are still 2.6.21). I still have the problem.
My current test file is a tar image of the gumstix-oe directory (tar cf gs-oe.tar gumstix-oe/). The file is about 390 MB.
I can use scp to write the file to the microSD card:
scp gs-oe.tar email@example.com:/media/card/test.tar
I've ruled out the ethernet interface by buying a microSD USB card reader/adapter and copying the file directly to the microSD card then with the microSD card in my gumstix:
dd if=/media/card/gs-oe.tar of=/media/card/test-2.tar
I've done this test several times (with various 'dd' block sizes) and rarely did the file get written without an error.
I've tried several microSD cards:
SanDisk 1GB (2)
SanDisk 8GB (SDHC)
I have tried a different netmicrosd board with the same results. I have a 'new' netwifimicrosd board on order.
Any suggestions on how to resolve this would be greatly appreciated.