From owner-freebsd-scsi  Fri Jul 12 12:56:12 1996
Return-Path: owner-freebsd-scsi
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA11560
          for freebsd-scsi-outgoing; Fri, 12 Jul 1996 12:56:12 -0700 (PDT)
Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11552;
          Fri, 12 Jul 1996 12:56:10 -0700 (PDT)
Message-Id: <199607121956.MAA11552@freefall.freebsd.org>
To: Nicolas Souchu <Nicolas.Souchu@prism.uvsq.fr>
cc: freebsd-scsi@freebsd.org
Subject: Re: TRY_AGAIN_LATER return value 
In-reply-to: Your message of "Fri, 12 Jul 1996 19:46:20 +0200."
             <199607121746.TAA00314@angrand.prism.uvsq.fr> 
Date: Fri, 12 Jul 1996 12:56:09 -0700
From: "Justin T. Gibbs" <gibbs@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.

It won't exist after I check in, so you should do more than consider
it. B-)

> > 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" ?

XS_BUSY means that the device returned BUSY status during the status phase
on the SCSI bus.  If you cannot handle more than one request at a time
per device, you should set the number of openings in the scsi_link template
accordingly.  If your queue is full, the upper level SCSI code should know
this by openings going to zero.  XS_BUSY has a limited number of retries.
A driver queue full error should retry once the queue is no longer full.

> > 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()).

You should use timeout() because you may not have a valid process context
when your driver is called.

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

Then openings (opennings in the current source) should be preset to 1
so that your driver will never get re-entered.

>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;

If openings is set correctly, you should be able to turn this into a panic
as it should never occur.

>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;

If you don't take it before the number of allowed retries are attempted,
the command will fail.

> > 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();

You shouldn't even need to sleep like this.  Return successfully queued
to the SCSI code and the process will sleep on the buffer.  Schedule a
timeout to poll the parallel port and when you return complete, the
process will get woken up.

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

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================