[Top] [All Lists]

Re: file corruption with highmem kernel

To: "Anoop P.A." <>
Subject: Re: file corruption with highmem kernel
From: Ralf Baechle <>
Date: Thu, 5 Aug 2010 19:25:47 +0100
Cc: linux-mips <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/1.5.20 (2009-12-10)
On Thu, Aug 05, 2010 at 06:43:50AM -0700, Anoop P.A. wrote:

> With a slightly modified patched (copied below) I have reached a point
> where I am no more seeing errors like segmentation fault, bus error
> (which was due to memory corruption I believe).
> How ever I am still seeing some kind of file corruption. 
> I believe this file corruption happening because cache is not getting
> invalidated before a highmem dma. I am not sure which routine to call to
> invalidate cache for a highmem address. 

Since you're running on an RM9000 class CPU, why don't just use a 64-bit
kernel?  Highmem is just so f*cking insane that you want to avoid it like
French kisses from a zombie suffering ebola.  If you have DMA restrictions
then you may consider reusing ZONE_DMA.

That said, a word on the history of the MIPS highmem code.  It was written
for a company who in the early stages of the 64-bit kernel didn't want to
be the first through the minefield in 2001.  That CPU had full coherency
and no cache aliases so arch/mips/mm/dma-*.c did not need any code to
support it at all and for many years after that everybody either had a
small 32-bit system that didn't need highmem or went 64-bit right away so
the gaps in the code while well known were never fixed up ...

I'm a bit surprised that the patch posted actually made things work better
for you since it entirely avoids flushing of highmem pages.  The code as it
was originally written using page_address() will perform cacheflushes
for highmem pages as well - but only for highmem pages are actually are
mapped.  That is your code will flush less pages than the existing code.


<Prev in Thread] Current Thread [Next in Thread>