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

Gérard Roudier (groudier@free.fr)
Sat, 29 Dec 2001 19:39:19 +0100 (CET)


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#.

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

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.

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):

/*
* Select all supported special features.
* If we are using on-board RAM for scripts, prefetch (PFEN)
* does not help, but burst op fetch (BOF) does.
* Disabling PFEN makes sure BOF will be used.
*/
if (np->features & FE_ERL)
np->rv_dmode |= ERL; /* Enable Read Line */
if (np->features & FE_BOF)
np->rv_dmode |= BOF; /* Burst Opcode Fetch */
if (np->features & FE_ERMP)
np->rv_dmode |= ERMP; /* Enable Read Multiple */
#if 1
if ((np->features & FE_PFEN) && !np->ram_ba)
#else
if (np->features & FE_PFEN)
#endif
np->rv_dcntl |= PFEN; /* Prefetch Enable */
if (np->features & FE_CLSE)
np->rv_dcntl |= CLSE; /* Cache Line Size Enable */
if (np->features & FE_WRIE)
np->rv_ctest3 |= WRIE; /* Write and Invalidate */
if (np->features & FE_DFS)
np->rv_ctest5 |= DFS; /* Dma Fifo Size */

+ #if 0 /* Disable all cache line based features */
+ np->rv_dcntl &= ~CLSE;
+ #endif
+ #if 1 /* Disable Read Line */
+ np->rv_dmode &= ~ERL;
+ #endif
+ #if 1 /* Disable Read Multiple */
+ np->rv_dmode &= ~ERMP;
+ #endif
+ #if 0 /* Disable Write and Invalidate */
+ np->rv_ctest3 &= ~WRIE;
+ #endif

This example disables Read Line and Memory Read Multiple. I just added
provisions (#if'ed zero) for other bits that also apply to cache line
based transactions.

Gérard.

-
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/