Date: Mon, 13 Sep 1999 09:55:13 -0600 From: "Justin T. Gibbs" <gibbs@caspian.plutotech.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@freebsd.org, anderson@cs.duke.edu, Don Lewis <Don.Lewis@tsc.tdk.com> Subject: Re: data corruption when using aic7890 Message-ID: <199909131555.JAA14180@caspian.plutotech.com> In-Reply-To: Your message of "Mon, 13 Sep 1999 11:45:57 EDT." <14301.2437.648605.15748@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>I've tried all the extremes, with the following results: > >RD_DFTHRSH_MAX | WR_DFTHRSH_MIN: corruption on read soon after first pas >s >RD_DFTHRSH_MIN | WR_DFTHRSH_MIN: corruption on read soon after first pas >s >RD_DFTHRSH_MAX | WR_DFTHRSH_MAX: immediate corruption (maybe write was c >orrupted?) >RD_DFTHRSH_MIN | WR_DFTHRSH_MAX: immediate corruption (maybe write was c >orrupted?) > >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? The docs are not immediately available. You need to sign a PUA (Publications Use Agreement) with adaptec (essentially a giant disclaimer) and then you can get the docs. The DMA engine on these chips shouldn't require any external intervention from the software side to deal with the FIFOs. You fire it up, and wait for it to complete. Perhaps if you can better characterize how the data is corrupted I can think of more things to check. I'll take a peek at the S/G and DMA handling code in the firmware later today regardless. -- Justin 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?199909131555.JAA14180>