Date: 14 Sep 1999 11:47:46 -0400 From: Andrew Heybey <ath@niksun.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-scsi@freebsd.org, gibbs@caspian.plutotech.com, anderson@cs.duke.edu, don.lewis@tsc.tdk.com Subject: Re: data corruption when using aic7890 Message-ID: <85aeqpfqal.fsf@stiegl.niksun.com> In-Reply-To: Andrew Gallatin's message of "Mon, 13 Sep 1999 11:45:57 -0400 (EDT)" References: <199909110138.TAA03862@caspian.plutotech.com> <14301.2437.648605.15748@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin <gallatin@cs.duke.edu> writes: > Justin T. Gibbs writes: > > >I would continue to tweak the variable. I assume you tried setting > > >the read threshold to MIN and the write threshold to MAX? In other > > >words, don't start a read from host memory until the FIFO is almost > > >empty, and don't start a write to host memory until the FIFO is almost > > >full. The assumption here is that PCI is faster than the SCSI bus > > >speed so we'll get the longest bursts this way. > > > > I misread the data book. If you set them both to MAX, then you would > > get this behavior. The read fifo threshold is based on the amount > > of empty space in the fifo, not the amount of data in it. > > > I've tried all the extremes, with the following results: > > RD_DFTHRSH_MAX | WR_DFTHRSH_MIN: corruption on read soon after first pass > RD_DFTHRSH_MIN | WR_DFTHRSH_MIN: corruption on read soon after first pass > RD_DFTHRSH_MAX | WR_DFTHRSH_MAX: immediate corruption (maybe write was corrupted?) > RD_DFTHRSH_MIN | WR_DFTHRSH_MAX: immediate corruption (maybe write was corrupted?) > > Before I go marching through all the combinations, is it possible that > there is a flag set someplace when a fifo overrun/underrun occurs that > you're not checking? Are the docs for this board available? > > BTW, in case I wasn't clear originally, I'm not just running the test > on 2 disks connected to the 7890 controller. I'm also running our > sequential read/write test on 2 identical disks connected to an ncr875 > controller & to an IDE drive connected to the built-in PIIX4. Eg, I'm > beating the snot out of the PCI bus by pushing about 50-70MB/sec of > data across it from 3 separate PCI devices, so its not unreasonable to > expect that a fifo might fill up under these conditions. Contention on the PCI bus seems to be the key to causing the problem. In my case it was 10MByte/s of network traffic (with 44K interrupts/sec) plus reading the disks as fast as possible. I never saw the problem with *just* reading disks, only when I added the network traffic. In your case you have multiple disk controllers fighting for the bus. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?85aeqpfqal.fsf>