From owner-cvs-sys  Wed Aug 13 11:04:39 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA16610
          for cvs-sys-outgoing; Wed, 13 Aug 1997 11:04:39 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA16496;
          Wed, 13 Aug 1997 11:03:28 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1])
	by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id LAA24046;
	Wed, 13 Aug 1997 11:59:37 -0600 (MDT)
Message-Id: <199708131759.LAA24046@Ilsa.StevesCafe.com>
X-Mailer: exmh version 2.0gamma 1/27/96
From: Steve Passe <smp@csn.net>
To: "Justin T. Gibbs" <gibbs@FreeBSD.ORG>
cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/dev/aic7xxx aic7xxx.reg aic7xxx.seq 
 src/sys/i386/scsi aic7xxx.c aic7xxx.h
In-reply-to: Your message of "Wed, 13 Aug 1997 10:02:49 PDT."
             <199708131702.KAA00482@freefall.freebsd.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Aug 1997 11:59:37 -0600
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Justin,

>   Modified files:
>     sys/dev/aic7xxx      aic7xxx.reg aic7xxx.seq 
>     sys/i386/scsi        aic7xxx.c aic7xxx.h 
>   Log:
>   Add a spin lock that prevents the sequencer from attempting to add an
>   entry to the QOUTFIFO when it is full.  This should eliminate the
>   "Timed out while idle" problems that many have reported.
>   
>   In truth, this is somewhat of a hack.  Although are interrupt latency is
>   low enough that we should be able to always service the queue in time,
>   since each entry must be passed up to the higher SCSI layer for what can
>   be a large amount of processing (perhaps even resulting in a new command
>   being queued) with interrupts disabled, we need this mechanism to avoid
>   overflow.  In the future, these additional tasks will be offloaded to a
>   software interrupt handler which should make this hack unnecessary.

For the record, disabled INTs was the reason that this was showing up in the
SMP kernel.  Because of a race in an unprotected critical region level-active
INTs (ie PCI) could sometimes be left masked when the relevant bit in ipending
was cleared, resulting in complete blockage of further INTs.  Although this
was clearly an SMP problem, having robustness in other parts of the system
is appreciated!

This leads to the question:  when INTs get totally blocked
like this, wont the system still freeze, ie should there be a timeout to
panic in your spin lock for times like this?

--
Steve Passe	| powered by
smp@csn.net	|            Symmetric MultiProcessor FreeBSD