[lkml]   [2001]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Sym53c8xx tape corruption squashed! (was: Re: SCSI Tape corruption - update)

    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)
    if (np->features & FE_PFEN)
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:14    [W:0.045 / U:221.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site