Date: Sat, 28 Aug 1999 11:26:08 -0700 From: Mike Smith <mike@smith.net.au> To: mjacob@feral.com Cc: Matthew Dillon <dillon@apollo.backplane.com>, "Justin T. Gibbs" <gibbs@plutotech.com>, hackers@FreeBSD.ORG Subject: Re: Should cam_imask be part of bio_imask ? Message-ID: <199908281826.LAA07726@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 28 Aug 1999 10:53:37 PDT." <Pine.BSF.4.05.9908281048170.8884-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> I strongly doubt that this is a CAM isr problem- the error pattern isn't
> entirely clear from what you said, but it looks more like a FIFO or CACHE
> LINE sized type of problem- it looks to be < 16 bytes, but not a short
> count. Because this isn't one of the wacky systems I spent most of my
> career on at Sun where the first and usual suspect was a system memory
> cache line because IO wasn't cache coherent on Suns between the Sun
> 3/{50,60,75,150} and the advent SuperSparc Viking Chipset, I'd guess a
> FIFO somewhere in the I/O movement path.
>
> Justin- any changes lately where flushing a FIFO in the Adaptec at the end
> of tranfer might have been spoodged?
If you happen to be using an Adaptec SCSI controller on the server,
check your PCI bus latency setting. We've seen several reports now of
this sort of stuff getting corrupted as a side-effect of the Adaptec
parts being arbitrated off the bus too quickly. If you're doing lots
of network traffic, the chances are a lot better that you'll hit this.
32 is a value that seems to cause problems; try 80 or so.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msmith@freebsd.org
\\ -- Joseph Merrick \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908281826.LAA07726>