From owner-freebsd-scsi Tue Aug 5 05:35:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA10408 for freebsd-scsi-outgoing; Tue, 5 Aug 1997 05:35:32 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10397 for ; Tue, 5 Aug 1997 05:35:28 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id HAA18841; Tue, 5 Aug 1997 07:49:17 -0400 (EDT) From: Peter Dufault Message-Id: <199708051149.HAA18841@hda.hda.com> Subject: Re: NOT READY In-Reply-To: <199708050302.UAA21425@silvia.HIP.Berkeley.EDU> from Satoshi Asami at "Aug 4, 97 08:02:56 pm" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 5 Aug 1997 07:49:16 -0400 (EDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > + scsi_start_unit(xs->sc_link, SCSI_ERR_OK | SCSI_SILENT); > + DELAY(5000000); This is a five second busy wait and will hang the system. You're in a done interrupt at this point so you can't sleep. I think a "SCSIRET_TRANSACTION_CONTINUES" up in scsi_base could be added so that this interrupt thread would go away without signalling any completion and then finish up this transaction up when the spliced in command completed. It would take some work to do properly and test. Try returning without the DELAY and hope the code that retries forever when something "is becoming ready" kicks in. It will still poll but at least it will stop as soon as it is ready. -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval