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

Geert Uytterhoeven (geert@linux-m68k.org)
Sat, 29 Dec 2001 22:28:07 +0100 (MET)


On Sat, 29 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> On Sat, 29 Dec 2001, Geert Uytterhoeven wrote:
> > On Sat, 29 Dec 2001, [ISO-8859-1] Gérard Roudier wrote:
> > > On Fri, 28 Dec 2001, Geert Uytterhoeven wrote:
> > > > 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.
> >
> > I played a bit with sym-2 and setpci. Everything goes fine as long as the PCI
> > latency timer value is smaller than 0x16 (yes, at first I thought it was
> > decimal, but setpci parameters are in hex).
>
> Interesting result, even if it doesn't trigger any of my guessing
> capabilities, for now. :-)
>
> Just it means that the 875 must release the PCI BUS if its GNT# signal is
> deasserted by PCI arbiter and current transaction lasted 22 PCI cycles or
> more since the assertion of FRAME#.

Exactly my thoughts.

> If I remember correctly, the problem occurred when data is written to the
> device. Is it ok?

Yes.

> If so, the MWI problem I pointed out in my previous posting is unlikely to
> apply. But, for user data DMA write, the 875 may execute Memory Read Line
> or Memory Read Multiple Lines transactions. It would be interesting to
> know if it makes difference disabling those capabilities.
>
> Setting to zero the PCI cache line register in the PCI configuration space
> does force the chip not to use any of the cache line based PCI
> transactions. It is brute force but should work.

Note that on my system the PCI cache line register in the PCI configuration
space of the '875 is already set to zero.

> In order to disable separately those features, some IO register bits must
> be set to zero. The faster way is to hack the driver (sym_hipd.c) at some
> place, for example (entered by hand just for you):

So I don't think it would help to test this, since PCI_CACHE_LINE_SIZE is set
to 0?

Anyway, thanks for your time and suggestions!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/