arm/158950: arm/sheevaplug fails fsx when mmap operations are enabled

[Ian Lepore]

On Wed, 2012-04-25 at 09:20 +0000, Kristof Provost wrote:
> The following reply was made to PR arm/158950; it has been noted by GNATS.
> 
> From: Kristof Provost <kristof at sigsegv.be>
> To: bug-followup at FreeBSD.org
> Cc:  
> Subject: Re: arm/158950: arm/sheevaplug fails fsx when mmap operations are
>  enabled
> Date: Wed, 25 Apr 2012 11:15:17 +0200
> 
>  The sample program above has the following output:
>  
>  root at openrd:/mnt# /bin/kp
>  After mmap: offset 32 is 0, not 32 as expected
>  After mmap: offset 33 is 0, not 33 as expected
>  After mmap: offset 34 is 0, not 34 as expected
>  ...
>  After mmap: offset 61 is 0, not 61 as expected
>  After mmap: offset 62 is 0, not 62 as expected
>  After mmap: offset 63 is 0, not 63 as expected
>  After mmap: offset 224 is 0, not 96 as expected
>  After mmap: offset 225 is 0, not 97 as expected
>  ...
>  
>  That's confirmed by hexdump-ing the test.img file afterwards.
>  
>  I'm also able to reproduce the problem described in arm/162159. You're
>  probably right about the relation.
>  
>  The problem looks very similar too: 32-byte sections that are 0 rather
>  than the expected values.

Whenever I run into IO corruption that comes in 32-byte chunks I
immediately suspect trouble in the busdma cacheline flush code.  A
useful first step in narrowing that down is to change the data cache
from write-back to write-through mode and see if the symptoms change.  I
think for a sheeva cpu you'd do that in pmap_pte_init_arm10() in
sys/arm/arm/pmap.c.  Change the xxx_cache_mode vars to be the same as
they are in the pmap_pte_init_arm9() function just above it.

-- Ian