On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> 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?
The only PCI transaction that requires the cache line size to be correctly
configured is PCI WRITE and INVALIDATE. This transaction may be used by
the 875 only for data read from a SCSI device and DMAed to memory.
Note that the controller may use optimized PCI transactions only if the
cache line size is configured in its PCI device configuration space.
Otherwise only normal PCI memory read and PCI memory write transactions
will be used.
Could you check if the cache line size is configured for your 875?
Let me imagine it is so. Btw, I may be wasting my time if it is not ...
Then the 875 may also use PCI read multiple transactions and/or PCI read
line transactions when reading data from memory. If the corruption is due
to the use of these transactions, the the PCI-HOST bridges may well be the
culprit, in my opinion.
Anyway, since the sym53c8xx driver does not try to change the configured
cache line size on PPC, I would suggest to try again the same tests with
the cache line size set to zero for the 875. You may hack the driver code
or the PPC pci code if needed, for example, for value zero to be written
in the proper place in the PCI configuration space of the 875.
Gérard.
-
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/
