From f8c5944d43059030b16172f2e2f2c28a8afcfcc5 Mon Sep 17 00:00:00 2001
From: "Justin T. Gibbs" <gibbs@FreeBSD.org>
Date: Fri, 9 Oct 1998 21:40:50 +0000
Subject: [PATCH] Only pull 16 bits of residual information from completing
 queues.  This is a work-around from an LRAM access bug on the 940UA.  In a
 future microcode revision, the high 16bits of residual information will be
 moved to a safe location and we'll return to 32bit residuals.  Since we only
 allow 64KB I/O, 16bits is enough.

---
 sys/dev/advansys/advlib.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/sys/dev/advansys/advlib.c b/sys/dev/advansys/advlib.c
index 3a7f6115289a..617266a6aa87 100644
--- a/sys/dev/advansys/advlib.c
+++ b/sys/dev/advansys/advlib.c
@@ -28,7 +28,7 @@
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.
  *
- *      $Id: advlib.c,v 1.6 1998/09/20 05:04:05 gibbs Exp $
+ *      $Id: advlib.c,v 1.7 1998/10/07 03:32:57 gibbs Exp $
  */
 /*
  * Ported from:
@@ -817,8 +817,16 @@ adv_copy_lram_doneq(struct adv_softc *adv, u_int16_t q_addr,
 	scsiq->sense_len = val & 0xFF;
 	scsiq->extra_bytes = (val >> 8) & 0xFF;
 
+	/*
+	 * XXX 
+	 * Due to a bug in accessing LRAM on the 940UA, we only pull
+	 * the low 16bits of residual information.  In the future, we'll
+	 * want to allow transfers larger than 64K, but hopefully we'll
+	 * get a new firmware revision from AdvanSys that address this
+	 * problem before we up the transfer size.
+	 */
 	scsiq->remain_bytes =
-	    adv_read_lram_32(adv, q_addr + ADV_SCSIQ_DW_REMAIN_XFER_CNT);
+	    adv_read_lram_16(adv, q_addr + ADV_SCSIQ_DW_REMAIN_XFER_CNT);
 	/*
 	 * XXX Is this just a safeguard or will the counter really
 	 * have bogus upper bits?