Hi,
> If that's the cause, it's probably a double down of the host scan
> semaphore somewhere in the code. alt-sysrq-t should work in this case,
> can you get a stack trace of the blocked process?
It appears to be this patch:
[SCSI] SCSI core: fix leakage of scsi_cmnd's
From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
This patch (as559b) adds a new routine, scsi_unprep_request, which
gets called every place a request is requeued. (That includes
scsi_queue_insert as well as scsi_requeue_command.) It also changes
scsi_kill_requests to make it call __scsi_done with result equal to
DID_NO_CONNECT << 16. (I'm not sure if it's necessary to call
scsi_init_cmd_errh here; maybe you can check on that.) Finally, the
patch changes the return value from scsi_end_request, to avoid
returning a stale pointer in the case where the request was requeued.
Fortunately the return value is used in only place, and the change
actually simplified it.
And in particular it looks like the scsi_unprep_request in
scsi_queue_insert is causing it. The following patch fixes the boot
problems on the vscsi machine:
Index: build/drivers/scsi/scsi_lib.c
===================================================================
--- build.orig/drivers/scsi/scsi_lib.c 2005-09-14 18:23:34.000000000 +1000
+++ build/drivers/scsi/scsi_lib.c 2005-09-14 18:27:33.000000000 +1000
@@ -188,7 +188,7 @@
* function. The SCSI request function detects the blocked condition
* and plugs the queue appropriately.
*/
- scsi_unprep_request(req);
+ //scsi_unprep_request(req);
spin_lock_irqsave(q->queue_lock, flags);
blk_requeue_request(q, req);
spin_unlock_irqrestore(q->queue_lock, flags);
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
