[610] in linux-scsi channel archive
Re: First stab at multiple initiators
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Sat Sep 9 22:07:51 1995
From: "Eric Youngdale" <eric@aib.com>
Date: Fri, 8 Sep 1995 10:41:30 -0400
In-Reply-To: mike@ringo.reno.nv.us (Michael Morrison)
"First stab at multiple initiators" (Sep 7, 12:40pm)
To: mike@ringo.reno.nv.us (Michael Morrison),
linux-scsi@vger.rutgers.edu (linux scsi)
>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
This is a guaranteed way to crash the system. In kernel mode, you
only get one page of memory for stack (4096 bytes). Exceed this, and
you corrupt something else. This usually leads to spontaneous reboots
of the machine.
Actually, I am not convinced that this is what you are actually
seeing. Internal_cmnd only queues the command to the host adapter. After
queueing, it should return and life should proceed. Once the host adapter
notices that there is a problem, an interrupt will be posted and the
status code will be returned indicating that the bus is busy. You end
up in an infinite loop, but you should not end up with stack growth.
Note that this is how things are intended to work with things like the
1542 - the aic7770 driver may do things differently and when we post the
command we already know that the device is busy and we end up with a loop
as you describe. I would view this as a bug in the aic7770 driver rather
than a problem with scsi.c
-Eric
--
"The woods are lovely, dark and deep. But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."
