[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, [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?


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



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:14    [W:0.080 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site