From owner-freebsd-scsi  Fri Jul 12 09:43:55 1996
Return-Path: owner-freebsd-scsi
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id JAA25144
          for freebsd-scsi-outgoing; Fri, 12 Jul 1996 09:43:55 -0700 (PDT)
Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA25139
          for <freebsd-scsi@freebsd.org>; Fri, 12 Jul 1996 09:43:50 -0700 (PDT)
Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1])
          by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id SAA16277
          ; Fri, 12 Jul 1996 18:43:37 +0200 (METDST)
Received: from angrand.prism.uvsq.fr (angrand.prism.uvsq.fr [193.51.25.85])
          by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id SAA10126
          ; Fri, 12 Jul 1996 18:43:36 +0200 (MET DST)
Received: from (son@localhost)
          by angrand.prism.uvsq.fr (8.7.5/jtpda-5.2) id TAA00314
          ; Fri, 12 Jul 1996 19:46:20 +0200 (MET DST)
Date: Fri, 12 Jul 1996 19:46:20 +0200 (MET DST)
Message-Id: <199607121746.TAA00314@angrand.prism.uvsq.fr>
From: Nicolas Souchu <Nicolas.Souchu@prism.uvsq.fr>
To: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
CC: freebsd-scsi@freebsd.org
Subject: Re: TRY_AGAIN_LATER return value 
In-Reply-To: <199607121602.JAA21617@freefall.freebsd.org>
References: <199607121351.PAA00186@angrand.prism.uvsq.fr>
	<199607121602.JAA21617@freefall.freebsd.org>
Sender: owner-freebsd-scsi@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Thanks for your reply.

 > HAD_ERROR has been removed.  You should return COMPLETE with a valid error
 > in the scsi_xfer structure.

We were already advised of this by scsi_base.c comments. I'll consider
it.

 > 
 > XS_BUSY means the target returned BUSY status, not that the driver is busy.
 > 	(Hmmm...  This should probably be determined by the upper level
 > 	 SCSI layer by looking at the status byte.  Perhaps XS_BUSY can go
 > 	 away too.)

I don't feel the difference... you mean, a request for a busy device
may be queued by the driver which isn't busy then ? This means the 
top SCSI layer expects the scsi_done() call but "after a moment" ?

 > I'll be sure to look into the deadlock you're seeing, but it sounds like
 > you are using the return codes in a very different way.  You should
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is surely the source of my bugs.

 > not be returning to the scsi system unless the buffer is filled or the
 > drive has reported an error.
...

More precisely, my driver polls the parallel port. When data are not
available, instead of doing an active wait on the port, I want to
schedule the process (tsleep() seems to be easier than timeout()).

Thus, I must care no other process will access the driver while the
process of the current request is asleep or timedout.

Then, the BUGGY source code of my scsi_cmd () was something like that:
(as it is in /sys/i386/isa/wd7000.c of the 2.1.0-RELEASE)

if (device->flags & IN_USE) {
  XS_ERROR = XS_DRIVER_STUFFUP;
  return HAD_ERROR;
} else
  device->flags |= IN_USE;

I replaced it by the following code, which is *probably* a fix:
-- I not sure yet :^( --

if (device->flags & IN_USE) {
  XS_ERROR = XS_TIMEOUT;
  return HAD_ERROR;
} else
  device->flags |= IN_USE;



 > Are you not able to sleep waiting for these resources as all the other
 > driver do?

Something like ... ?

splbio();
while (device->flags & IN_USE) {
	tsleep (PRIBIO);
}
device->flags |= IN_USE;
splx();


nicolas

-- 
Nicolas.Souchu@prism.uvsq.fr
Laboratoire PRiSM - Versailles, FRANCE