Highmem issues with MMC filesystem

[Nicolas Pitre]

On Thu, 18 Mar 2010, Russell King - ARM Linux wrote:

> On Thu, Mar 18, 2010 at 07:00:06PM +0530, Shilimkar, Santosh wrote:
> > Or could it be that there is appropriate cacheflush happening but data gets
> > stuck in CPU writebuffers instead of reaching to main memory. In this case
> > too DMA won't see the contents and a barrier (dsb) is necessary to ensure
> > that write buffer is drained before DMA takes over the buffer.

No, this is not the issue.

> What exactly is the problem that we're discussing?  Is it that the data
> on the block device is becoming corrupted, or is the data being read off
> the block device corrupted?

Data read from a DMA based block device is corrupted in memory and 
causing all sorts of misbehavior such as segmentation faults in user 
space, or EXT2 complaining about broken filesystem metadata.  This is 
serious enough to prevent a successful boot to a login prompt.  Of 
course the filesystem is just fine as using the same kernel and limiting 
the memory size so highmem doesn't get involved "fixes" the issue.  
Also keeping highmem pages active and adding a couple flush_cache_all() 
in some places also apparently "fixes" the issue.

Given that systems with VIVT caches have a full cache flush on each task 
switch, I added such a cache flush in the ARMv6 case as well to see what 
would happen.  And this _almost_ "fixed" the issue as long as there is 
enough running tasks at once on the system to enforce that cache flush 
often enough.  But with a single task running, such as gcc, then the 
segmentation faults come back.

See my previous email for my current hypothesis about the actual 
problem.


Nicolas