Re: SCSI woes (followup)

James Bottomley
2002-09-24T13:46:31Z

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

rmk@arm.linux.org.uk said:
> I'm getting the impression that the door lock handling code is
> misplaced, and is probably the cause of these problems. I'm going to
> try disabling that code, and reverting my previous change to
> scsi_restart_operations().

Unfortunately, if we want to ensure the medium is locked in place, the lock
has to occur that low down (since error recovery can unlock the door and a
retry doesn't currently trouble the upper layers).

I think it's method of operation is misplaced. What it should probably be
doing is simply adding a doorlock to the head of the queue and then go back
around. Since we know the doorlock now preceeds the command that instigated
the issue the door should be locked before anything else happens. It should
simply loop around and process the door lock request so it doesn't have to
wait for anything else to occur (any commands which come down in the interim
should go on the queue tail).

However, for your case does simply moving the queue empty check to the top
cause the problems to go away? (That would be hiding the problem not fixing
it, but still...)

James

[-- Attachment #2: tmp.diffs --]
[-- Type: text/plain , Size: 775 bytes --]

===== scsi_lib.c 1.15 vs edited =====
--- 1.15/drivers/scsi/scsi_lib.c Tue Aug 13 09:35:17 2002
+++ edited/scsi_lib.c Tue Sep 24 09:45:16 2002
@@ -868,6 +868,15 @@
if (SDpnt->device_blocked) {
break;
}
+
+ /*
+ * If we couldn't find a request that could be queued, then we
+ * can also quit.
+ */
+
+ if (list_empty(&q->queue_head))
+ break;
+
if ((SHpnt->can_queue > 0 && (SHpnt->host_busy >= SHpnt->can_queue))
|| (SHpnt->host_blocked)
|| (SHpnt->host_self_blocked)) {
@@ -914,13 +923,6 @@
continue;
}
}
-
- /*
- * If we couldn't find a request that could be queued, then we
- * can also quit.
- */
- if (list_empty(&q->queue_head))
- break;

/*
* Loop through all of the requests in this queue, and find