On Mon, Jul 27, 2009 at 2:32 PM, Seth Forshee <seth.fors...@gmail.com>wrote:
> I'm opening an MMC block device node with O_DIRECT on an MSM7k series > processor with Android (sort of a stress test, and I want to be sure > reads and writes go to the device and not just to the block cache). I'm > seeing that the data read back doesn't match the data written. There > are known problems with O_DIRECT on ARM with aliasing VIPT caches, > discussed at length on this thread: > > http://lkml.indiana.edu/hypermail/linux/kernel/0811.2/01044.html > > Based on that discussion, writes should be okay, but there may be > alaiasing with PIO reads if the driver doesn't call flush_dcache_page() > after the transfer. However, I am seeing problems on writes, and I > don't see this issue at all on another ARMv6TEJ-based board I have > running 2.6.31-rc4 (with glibc-based userspace, not Android) and having > an aliasing VIPT cache. The data errors I see look like they could > certainly be from cache aliasing though -- the incorrect data always > comes in 32-byte chunks aligned to a 32-byte boundary, and the data is > always the same as what should have been written at the same offset in > the previous data transfer. So I'm suspecting aliasing at this point, > but I'm still considering that it could be something else. > > I'm attaching source for a read/write test that produces this behavior. > All it does is iterate over the entire device, writing a 64KB, > locally-unique data pattern using O_DIRECT and reading the data back into > a seperate buffer for verification. I'm seeing failed verification > almost every time I run the test with a 2 GB SD card. > I'll try your test code when I have a chance. > > I'm in a difficult debugging sitation for this issue. I can't build the > kernel for the device (I'm working on getting the source to allow me to > do this), and I don't have documentation for the processor. I also > don't know whether the msm_sdcc driver is using DMA or PIO for the > transfer, although in my tracing of the code paths it doesn't look like > it should matter because in either case the cache lines for the > userspace mapping should be cleaned and invalidated before the transfer > starts. Are there any peculiarities of Android kernel modifications or > of the MSM7k that could be causing this sort of behavior? > I can't think of anything specific in the Android kernel patches which would cause the behavior you're seeing. For SD cards basically we DMA for any transfers >= 64 bytes and which are 64 byte aligned. > > Thanks, > Seth > > > > -- ---------- San Mehat Staff Software Engineer Google Inc. o: 650-253-7422 c: 408-382-1249 s...@google.com --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel -~----------~----~----~----~------~----~------~--~---
