On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > Is the corruption reproducible? If so, does the corruption go away if
>
> Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
> tape (I used a new one).
> - test 1: 4 files with failed md5sum (no further investigation on type of
> corruption)
> - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> corrupted, all starting at an offset of the form 32*x+1.
> - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> corrupted, all starting at an offset of the form 32*x+1.
>
> The files seem to be corrupted during writing only, as reading always gives the
> exact same (corrupted) data back.
>
> Copying files from the disk on the MESH to a disk on the Sym53c875 (which also
> has the tape drive) shows no corruption.
I did some more tests:
- The problem also occurs when tarring up files from a disk on the Sym53c875.
- The corrupted data always occurs at offset 32*x (the `+1' above was caused
by hexdump, starting counting at 1).
- The 32 bytes of corrupted data at offset 32*x are always a copy of the data
at offset 32*x-10240.
- Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball
on disk instead of on tape, but no corruption.
- 32 is the size of a cacheline on PPC. Is there a missing cacheflush
somewhere in the Sym53c875 driver? But then it should happen on disk as
well?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
