SCSI disconnect behaviour (fwd)

Carsten Pluntke (su0289@sx2.hrz.uni-dortmund.de)
Mon, 7 Sep 1998 11:31:10 +0200 (MET DST)


Hello,

Having some problems with my scanner I had to browse through the code of
the NCR53C9x.c SCSI device driver, but my question doesn't refer to that
particular driver, it's a bit more general...

I found that the device driver wouldn't execute other SCSI commands, even
to other targets if there is a target which has a disconnected command,
therefor a scanner (in my case) which readies itself and kindly
disconnects from the SCSI bus would block all other activities on it
because the device driver waits until the command is really finished.

Before regarding this behaviour as a bug, I'd like to know if it may be
intentional because some SCSI commands which may be executed in
disconnected state may rely on each other and shouldn't be mixed in the
order of execution.

On the other hand that behaviour may be prone to cause deadlocks. I just
imagine a heavily loaded system which tries to desperately swap out some
memory on a SCSI device which is blocked by a disconnected command on
another SCSI device and the operation which invoked the disconnected
command may require even more memory...

Any ideas? I mean, should other targets be accessible if one target has
disconnected and processes its command? Or is there a reason not to do so?

Carsten

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html