Subject: Re: "pmap_unwire: wiring ... didn't change!"
To: Chuck Silvers <email@example.com>
From: Markus W Kilbinger <firstname.lastname@example.org>
Date: 02/14/2005 21:37:40
>>>>> "Chuck" == Chuck Silvers <email@example.com> writes:
>> My mentioned tests, where I can reproduce the data corruption
>> certainly, involve disk access; _reading_ large data amounts
>> from disk is enough to get a corruption.
Chuck> so you get different corruption when you read the same file
Chuck> at different times? that's useful to know.
Yes: A (large) file that was intact a first time seems to be corrupt
when reading it later a second time (and vice versa).
For me it seems I can diminish these corrutions by putting some other
load on the qube2. On the other hand pure disk access (e. g. untarring
new base.tgz :-/)) produces quite certainly some corrupt files
(libc.so... :-(). To workaround the latter I run 'nice pax -zvrpe ...'
over a ssh connection, so that pax's '-v' vorbose output produces some
additional load which prevents most file corruptions (not all: some,
especially larger files might still get corrupted).
>> Hmm, if the problems occurs on quite different hardware, just
>> having the same mips CPU type, (common) r5k cache handling
>> seems really to be the most probable cause of the corruption
>> (correct?). Or ist bus_dma still a candidate?
Chuck> could be either, we don't know yet. the various versions of
Chuck> the bus_dma code for all the MIPS3 platforms are pretty
...despite the fact that the same bus_dma code works for/on your R4k4?
Chuck> FYI, I'm probably not going to have time to pursue this
Chuck> cache problem soon, so hopefully one of the other MIPS guys
Chuck> can run with it.
Maybe I should send-pr now (more precisely)?