On Sun, Feb 13, 2005 at 12:02:39PM +0100, Markus W Kilbinger wrote:
> >>>>> "Chuck" == Chuck Silvers <chuq@chuq.com> writes:
> 
>     Chuck> I looked into the "pmap_unwire: wiring ... didn't change!"
>     Chuck> problem. [...]
> 
> Thanks for doing that! :-)
> 
>     Chuck> the last one was the easiest, so I implemented that one and
>     Chuck> it appears to make the problem go away.
> 
> I've applied your patch and I can confirm vanishing of the
> "pmap_unwire: ..." messages (so far, 2 hours now).

cool.


> But I still see (my?) data corruption problem:
> 
>   http://mail-index.netbsd.org/port-cobalt/2004/11/04/0000.html
> 
> ... still 32 bytes long and at 32 bytes boundary, maybe related to
> 
>   cpu0 at mainbus0: QED RM5200 CPU (0x28a0) Rev. 10.0 with built-in FPU Rev. 10.0
>   cpu0: 32KB/32B 2-way set-associative L1 Instruction cache, 48 TLB entries
>   cpu0: 32KB/32B 2-way set-associative write-back L1 Data cache
> 
> While digging in that do you see any reason for their appearing?

that sounds like a CPU cache problem to me too, probably in bus_dma or the
cache-flushing code itself.  if it's happening during writes to disk rather
than reads from disk then it's probably in the cache write-back part rather
than the cache invalidate part.  I didn't see anything in a brief look at
the code, though.

I don't see this problem on my R4400 pmax 5000/260, so it's likely specific
to either the RM5200/R5000 or systems with no L2 cache.  do RM5200/R5000
systems with L2 cache (eg. sgimips) see this?  do we support any other
MIPS variants with no L2 cache?  maybe some of the hpcmips doodads?

from the RM5200 manual, it looks like it's possible to use the cache in
write-through mode instead of write-back mode, it might be worthwhile to
try doing that as an experiment to narrow down the problem.

-Chuck