>>>>> "Chuck" == Chuck Silvers <chuq@chuq.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
    Chuck> similar.

...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)?

Markus.