From owner-freebsd-scsi@FreeBSD.ORG  Thu Aug  7 15:36:18 2003
Return-Path: <owner-freebsd-scsi@FreeBSD.ORG>
Delivered-To: freebsd-scsi@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3B58F37B401
	for <freebsd-scsi@freebsd.org>; Thu,  7 Aug 2003 15:36:18 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8D7AD43FB1
	for <freebsd-scsi@freebsd.org>; Thu,  7 Aug 2003 15:36:17 -0700 (PDT)
	(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
	id <305LHP7Y>; Thu, 7 Aug 2003 18:36:16 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337027421B3@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: Dave Dolson <ddolson@sandvine.com>,
	"'freebsd-scsi@freebsd.org'" <freebsd-scsi@freebsd.org>
Date: Thu, 7 Aug 2003 18:36:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Swapping deadlock due to aic/scsi errors?
X-BeenThere: freebsd-scsi@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: SCSI subsystem <freebsd-scsi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-scsi>
List-Post: <mailto:freebsd-scsi@freebsd.org>
List-Help: <mailto:freebsd-scsi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2003 22:36:18 -0000

> From: Dave Dolson [mailto:ddolson@sandvine.com]
 ...
> > 
> > The "lost command" is supposed to be detected by the timeout
> > handler in the ahd driver.  The timeout handler just forces
> > a bus reset which should cause the command to be returned to
> > the SCSI layer and then retried.  It's not clear to me why
> > this might not be happening, but the ahd driver was relatively
> > green in 4.7 and you may just be tripping over a known (and
> > later corrected) bug manifesting itself in an unusual way.
> 
> Are you referring to the timeout handler ahd_timeout() ?
> Are the commmands retried from ahd_reset_channel() ?
> (It looks more like they're simply aborted.)
> 
> Aside: Am I correct in believing that ahd_execute_scb() is called 
> for every command to the drive?

It appears that if we set vm.swap_async_max=64 with sysctl, that 
the problem may no longer be reproducible. The default value seems
to be 4. The system is deadlocking looking for these async buffers.

Does this make sense?