Thread (33 messages) 33 messages, 5 authors, 2006-02-09

Re: [PATCH 07/13] SCSI: export scsi_eh_finish_cmd() and scsi_eh_flush_done_q()

From: Jeff Garzik <hidden>
Date: 2006-01-24 17:30:23
Also in: linux-scsi

On Tue, Jan 24, 2006 at 09:11:17AM -0800, Luben Tuikov wrote:
So when scsi_finish_command() is unexported, then _all_ EH strategies
would have to define local done_q, and splice eh_cmd_q into local work_q,
then from local work_q into local done_q and then that is passed
to SCSI Core, via scsi_eh_flush_done_q().

Is it possible that this is done asynchrounously?  Since EH recovery is
per host, but you may have only a single device which is misbehaving?
No, because the host is stopped during EH, and only restarted after your
EH code completes its run.

I.e. is it possible, in a such and such EH strategy, not necessarily
SCSI Cores's or libata's, to _not_ have a local done_q?  So that,
we have only local work_q (after splicing eh_cmd_q) and after each
command is looked at, we "return" that command back to SCSI Core, so
that SCSI Core can "finish" it. (In effect "per-command", as opposed to
"per-queue-of-commands".)
done_q is simply a method for returning one or more commands back to the
SCSI Core, so that the SCSI Core can finish it.

Per-command is irrelevant during EH, because queue processing is not
restarted until your EH handler ends completely.

One alternative strategy for EH is to override the ->eh_timed_out()
function.  Its ugly, but you may effectively eliminate EH handling via
->eh_strategy_handler(), by moving the error handling completely within
(a) the interrupt handler or (b) ->eh_timed_out().

	Jeff


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help