Re: Sym53c8xx tape corruption squashed! (was: Re: SCSI Tape corruption

[Geert Uytterhoeven]

On Sat, 29 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> On Fri, 28 Dec 2001, Geert Uytterhoeven wrote:
> > The problem is introduced in 1.5pre-g2 by the following change:

  [...]

> > This change causes the PCI latency timer to be changed from 0 to 80.
> >
> > The sym-2 driver has a define for modifying the PCI latency timer
> > (SYM_SETUP_PCI_FIX_UP), but it is never used, so I see no corruption.
> 
> By default sym-2 use value 3 for the pci_fix_up (cache line size + memory
> write and invalidate). The latency timer fix-up has been removed, since it
> is rather up to the generic PCI driver to tune latency timers.
> 
> > Is this a hardware bug in my SCSI host adapter (53c875 rev 04) or my host
> > bridge (VLSI VAS96011/12 Golden Gate II for PPC), or a software bug in the
> > driver (wrong burst_max)?
> 
> Great bug hunting!
> 
> It is about certainly not a software bug in the driver. Any latency timer
> value should not give any trouble if hardware was flawless. Just the PCI
> performances could be affected.
> 
> Anyway, value 0 looks way stupid for devices capable of bursting more than
> 1 data phase, thus the improvement above. :)

OK.

> > To recapitulate, the bug causes error bursts of (almost always) 32 bytes long.
> > The incorrect bytes are always a copy of previous data, at a fixed offset (10
> > kiB on my (now dead) DDS-1 tape drive, 32 kiB on my Plexwriter).
> 
> Unfortunately, I haven't the errata listing for teh 53c875 rev 4. I have
> the DEL for 875 rev. 3 and for 876 rev. 5.

And I'm afraid I won't be able to get errata for the VLSI VAS96011/12 :-( Of
course I can always give it a try...

> If we assume that rev 4 hasn't more bugs than rev 3, then you may try to
> disable MEMORY WRITE and INVALIDATE (and not tell the driver to fix this
> up) but allow the driver to fix the bogus zero latency timer. The 875 rev
> 3 may, under certain conditions, execute unaligned PCI MEMORY WRITE and
> INVALIDATE transactions. Note that this may explain data corruptions
> occurring for SCSI READ commands not WRITE commands. No other items can
> explain, on paper, data corruptions of the form you describe due to 875
> chip misbehaviour.

I'll give that a try...

> Btw, latency timer zero should not change the likelyhood of this item.
> This let me think that the host bridge is likely to be the culprit.

Hmmm... I'm still wondering why I see the problem when writing to tape or
CD-R(W), while I can't provoke it when writing to disk (Quantum Viking II U2W).

What's so special about tape and CD-R?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]

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