[607] in linux-scsi channel archive
First stab at multiple initiators
daemon@ATHENA.MIT.EDU (Michael Morrison)
Fri Sep 8 08:11:02 1995
From: mike@ringo.reno.nv.us (Michael Morrison)
To: linux-scsi@vger.rutgers.edu (linux scsi)
Date: Thu, 7 Sep 1995 12:40:07 -0700 (PDT)
Hi all,
Today we tried to use multiple initiators on the same SCSI bus
and found the following problems.
It almost works but....
In scsi_done(), when a bus busy condition is detected, the command is
retried and internal_cmnd() is called. Internal_cmnd calls scsi_done().
This happens over and over until either the bus isn't busy
and the command completes, or the machine locks up. At first glance,
it looks like internal_cmd() and scsi_done() are called recursively
which I think is where the problem lies. The stack grows and grows until
the system hangs. I think one solution is to restrict the number of
retries performed for a given operation and then return an error
up to the higher level driver. Another related problem is the frequency
of the retries. Our analyzer showed that the retry was performed about
every 200ms. That stack is a growin fast! Perhaps a small delay should
happen between retries. I'm wondering what the proper number of retries
should be and also, I'd like to get some input from all you scsi hackers out there
who might have an opinion on this problem.
Another solution would be to get rid of the recursion, but that looks
like a major rewrite of scsi.c. Even if this was done, a maximum retry
count would be needed to avoid retrying the command forever if the
bus was never free.
Setup:
SGI with initiator at ID 0,
SDL SCSI Frame buffer at ID 3
Linux initiator at ID 7. (aix7xxx driver in 1.3.20)
Test condition
The SGI starts sending data to the Frame buffer target. This cause
the bus to be busy most of the time.
The Linux system issues an inquiry command via the generic driver.
About 1/2 the time the command will complete after an indeterminate
number of retries. If the command cannot get in, the system locks up.
Any insight into this will be appreciated, I'd like to get some feedback
before I go hacking.
Thanks
mike
mike@ringo.reno.nv.us
