On Tue, 8 May 2001, Geert Uytterhoeven wrote:
> In the mean time I down/upgraded to 2.2.17 on my PPC box (CHRP LongTrail,
> Sym53c875, HP C5136A DDS1) and I can confirm that the problem does not happen
> under 2.2.17 neither.
>
> My experiences:
> - reading works fine, writing doesn't
Same here
> - 2.2.x works fine, 2.4.x doesn't (at least since 2.4.0-test1-ac10)
SAME here
> - hardware compression doesn't matter
SAME HERE
> - I have a sym53c875, Lorenzo has an Adaptec, so most likely it's not a
> SCSI hardware driver bug
> - I have a PPC, Lorenzo doesn't, so it's not CPU-specific
> - corruption is always a block of 32 bytes being replaced by 32 bytes from
> the previous tape block (depending on block size!) (approx. 6 errors per
> 256 MB)
YESSS... EXACTLY 32 consecutive bytes are different. I'll bet we've got
the same problem
> - How many successive bytes are corrupted?
> - Where do the corrupted data come from?
Hmmmm.... I'll set up some sort of binary pattern match. This afternoon
I'll pinpoint the source of the rogue bytes...
-- Lorenzo Marcantonio
-
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/
