Date: Fri, 12 Jul 1996 12:56:09 -0700 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Nicolas Souchu <Nicolas.Souchu@prism.uvsq.fr> Cc: freebsd-scsi@freebsd.org Subject: Re: TRY_AGAIN_LATER return value Message-ID: <199607121956.MAA11552@freefall.freebsd.org> In-Reply-To: Your message of "Fri, 12 Jul 1996 19:46:20 %2B0200." <199607121746.TAA00314@angrand.prism.uvsq.fr>
index | next in thread | previous in thread | raw e-mail
>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
===========================================
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607121956.MAA11552>