From owner-cvs-all  Thu Jul 27 16:18: 3 2000
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3E12937C148; Thu, 27 Jul 2000 16:17:53 -0700 (PDT)
	(envelope-from gibbs@FreeBSD.org)
Received: (from gibbs@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id QAA42523;
	Thu, 27 Jul 2000 16:17:53 -0700 (PDT)
	(envelope-from gibbs@FreeBSD.org)
Message-Id: <200007272317.QAA42523@freefall.freebsd.org>
From: "Justin T. Gibbs" <gibbs@FreeBSD.org>
Date: Thu, 27 Jul 2000 16:17:53 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/dev/aic7xxx ahc_pci.c aic7xxx.h aic7xxx.reg
         aic7xxx.seq
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

gibbs       2000/07/27 16:17:53 PDT

  Modified files:
    sys/dev/aic7xxx      ahc_pci.c aic7xxx.h aic7xxx.reg 
                         aic7xxx.seq 
  Log:
  ahc_pci.c:
  	Disable "cache line streaming" for aic7890/91 Rev A chips.  I
  	have never seen these chips fail using this feature, but
  	some of Adaptec's regression tests have.
  
  	Explicitly set "cache line streaming" to on for aic7896/97
  	chips.  This was happening before, but this documents the
  	fact that these chips will not function correctly without
  	CACHETHEEN set.
  
  aic7xxx.h:
  	Add new bug types.
  
  	Fix a typo in a comment.
  
  aic7xxx.reg:
  	Add a definition for the SHVALID bit in SSTAT3 for Ultra2/3
  	chips.  This bit inicates whether the bottom most (current)
  	element in the S/G fifo has exhausted its data count.
  
  aic7xxx.seq:
  	Be more careful in how we turn off the secondary DMA channel.
  	Being less careful may hang the PCI bus arbitor that negotiates
  	between the two DMA engines.
  
  	Remove an unecessary and incorrect flag set operation in
  	the overrun case.
  
  	On Ultra2/3 controllers, clear the dma FIFO before starting
  	to handle an overrun.  We don't want any residual bytes from
  	the beginning of the overrun to cause the code that shuts
  	down the DMA engine from hanging because the FIFO is not
  	(and never will be) empty.
  
  	If the data fifo is empty by the time we notice that a
  	read transaction has completed, there is no need to
  	hit the flush bit on aic7890/91 hardware that will not
  	perform an auto-flush.  Skip some cycles by short circuiting
  	the manual flush code in this case.
  
  	When transitioning out of data phase, make sure that we
  	have the next S/G element loaded for the following
  	reconnect if there is more work to do.  The code
  	would do this in most cases before, but there was
  	a small window where the current S/G element could
  	be exhausted before our fetch of the next S/G element
  	completed.  Since the S/G fetch is already initiated
  	at this point, it makes sense to just wait for the
  	segment to arrive instead of incuring even more latency
  	by canceling the fetch and initiating it later.
  
  	Fast path the end of data phase handling for the last
  	S/G segment.   In the general case, we might have
  	worked ahead a bit by stuffing the S/G FIFO with
  	additional segments.  If we stop before using them
  	all, we need to fixup our location in the S/G stream.
  	Since we can't work past the last S/G segment, no
  	fixups are ever required if we stop somewhere in
  	that final segment.
  
  	Fix a little buglet in the target mode dma bug handler.
  	We were employing the workaround in all cases instead
  	of only for the chips that require it.
  
  	Fix the cause of SCB timeouts and possible "lost data"
  	during read operations on the aic7890.  When sending
  	a data on any Ultra2/3 controller, the final segment
  	must be marked as such so the FIFO will be flushed and
  	cleaned up correctly when the transfer is ended.  We
  	failed to do this for the CDB transfer and so, if
  	the target immediately transfered from command to data
  	phase without an intervening disconnection, the first
  	segment transferred would be any residual bytes from
  	the cdb transfer.  The Ultra160 controllers for some
  	reason were not affected by this problem.
  
  Many Thanks to Tor Egge for bringing the aic7890 problem
  to my attention, providing analysis, as well as a mechanism
  to reproduce the problem.
  
  Revision  Changes    Path
  1.33      +18 -2     src/sys/dev/aic7xxx/ahc_pci.c
  1.22      +13 -3     src/sys/dev/aic7xxx/aic7xxx.h
  1.23      +2 -1      src/sys/dev/aic7xxx/aic7xxx.reg
  1.98      +41 -13    src/sys/dev/aic7xxx/aic7xxx.seq



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message