Do an agent reset on error recovery.
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
(added Cc: LSML)
Quoted 2 lines · Kristian Høgsberg
Also, implement the .eh_host_reset_handler callback instead of .eh_abort_handler since that's what we're actually doing.
You reset the target port (or specifically, the fetch agent acting on that target port). But the .eh_host_reset_handler is to "ask [the] host adapter to reset itself". Or in the words of scsi_mid_low_api.txt:
eh_abort_handler - abort given command eh_bus_reset_handler - issue SCSI bus reset eh_device_reset_handler - issue SCSI device reset eh_host_reset_handler - reset host (host bus adapter)
The closest concept to "host bus adpaters" in SBP-2 are initiator ports, and there is no notion of resetting an SBP-2 initiator port.
But theoretic semantics aside: Check drivers/scsi/scsi_error.c for what comes after one or another hostt->eh_ handler was called. Do you want the subsequent call to scsi_report_bus_reset()? Probably not. But perhaps you want what comes after hostt->eh_device_reset_handler was called.
Quoted 35 lines
Signed-off-by Kristian Høgsberg <[email protected]>--- drivers/firewire/fw-sbp2.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)drivers/firewire/fw-sbp2.c +5
-4@@ -1068,12 +1068,13 @@ static int sbp2_scsi_slave_configure(struct scsi_device *sdev)* Called by scsi stack when something has really gone wrong. Usually * called when a command has timed-out for some reason. */ -static int sbp2_scsi_abort (struct scsi_cmnd *cmd) +static int sbp2_scsi_host_reset_handler (struct scsi_cmnd *cmd) { -struct fw_unit *unit = (struct fw_unit *)cmd->device->host->hostdata[0 ]; +struct fw_unit *unit = + (struct fw_unit *) cmd->device->host->hostdata[0 ];fw_notify ("sbp2_scsi_abort\n" ); - +sbp2_agent_reset (unit);sbp2_cancel_orbs (unit);return SUCCESS ;@@ -1086,7 +1087,7 @@ static struct scsi_host_template scsi_driver_template = { .queuecommand = sbp2_scsi_queuecommand, .slave_alloc = sbp2_scsi_slave_alloc, .slave_configure = sbp2_scsi_slave_configure, - .eh_abort_handler = sbp2_scsi_abort, + .eh_host_reset_handler = sbp2_scsi_host_reset_handler, .this_id = -1, .sg_tablesize = SG_ALL, .use_clustering = ENABLE_CLUSTERING,
Signature · 9 lines
Stefan Richter -=====-=-=== -=-- -=-== http://arcgraph.de/sr/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Quoted 7 lines · I wrote:
Quoted 2 lines · Kristian Høgsberg
Also, implement the .eh_host_reset_handler callback instead of .eh_abort_handler since that's what we're actually doing.
You reset the target port (or specifically, the fetch agent acting on that target port). But the .eh_host_reset_handler is to "ask [the] host adapter to reset itself".
...
Quoted 4 lines
But theoretic semantics aside: Check
drivers/scsi/scsi_error.cfor what comes after one or anotherhostt->eh_handler was called. Do you want the subsequent call toscsi_report_bus_reset()? Probably not. But perhaps you want what comes afterhostt->eh_device_reset_handlerwas called.
BTW, as you probably know there are different ways to (try to) bring an SBP-2 target back to reason. A while ago someone posted an extended abort/reset scheme but I still haven't looked into it in detail and tested it for its practical effects.
http://me.in-berlin.de/~s5r6/linux1394/work-in-progress/sbp2-scsi-abort-and-reset-of-non-responding-devices.patch
Signature · 7 lines
Stefan Richter -=====-=-=== -=-- -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Stefan Richter
(added Cc: LSML)
Quoted 2 lines · Kristian Høgsberg
Also, implement the .eh_host_reset_handler callback instead of .eh_abort_handler since that's what we're actually doing.
Quoted 7 lines
You reset the target port (or specifically, the fetch agent acting on that target port). But the .eh_host_reset_handler is to "ask [the] host adapter to reset itself". Or in the words of scsi_mid_low_api.txt:
eh_abort_handler- abort given commandeh_bus_reset_handler- issue SCSI bus reseteh_device_reset_handler- issue SCSI device reseteh_host_reset_handler- reset host (host bus adapter)
Yeah, and as I understand it, ideally you implement the most specific cancellation callback, i.e. if your controller can cancel a specific command the SCSI stack will use that, but fall back to more and more broad cancel functions.
The reason I made this change was that I was looking at sbp2.c, at the way it handles cancellation looks wrong to me. It implements both abort_handler and device_reset, but the only command it sends to the device in either case it an agent reset. As I understand the SCSI error handling, the device_reset is only called if abort_handler fails to abort the command. What's an extra agent reset going to do then? And the sbp2.c abort_handler always returns SUCCESS, btw.
So unless we want to implement "abort task" (finer grained) or target reset/write RESET_START to STATE_SET (coarser grained) it doesn't make
sense to have more than one error handler callback. And since we
have one SCSI host per fetch agent, it doesn't make much of a difference which error handler we implement.
Quoted 2 lines
The closest concept to "host bus adpaters" in SBP-2 are initiator ports, and there is no notion of resetting an SBP-2 initiator port.
Could a fetch agent not be viewed as a host bus adapter? The way I see it is that it has a set of registers that are available to the CPU through some bus. In this case the bus is IEEE1394 but it could be the PCI bus.
Quoted 4 lines
But theoretic semantics aside: Check
drivers/scsi/scsi_error.cfor what comes after one or anotherhostt->eh_handler was called. Do you want the subsequent call toscsi_report_bus_reset()? Probably not. But perhaps you want what comes afterhostt->eh_device_reset_handlerwas called.
This is the call chain:
if (__scsi_try_to_abort_cmd(scmd) != SUCCESS)
if (scsi_try_bus_device_reset(scmd) != SUCCESS)
if (scsi_try_bus_reset(scmd) != SUCCESS)
scsi_try_host_reset(scmd);We don't support aborting individual commands or individual LUNs, and we're not doing a SCSI bus reset... I dunno, I think the host reset seems appropriate, but I don't really know much about SCSI :)
cheers,
Kristian
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
Kristian Høgsberg wrote:
[hostt->eh_ flavors]
Quoted 7 lines
The reason I made this change was that I was looking at
sbp2.c, at the way it handles cancellation looks wrong to me. It implements bothabort_handleranddevice_reset, but the only command it sends to the device in either case it an agent reset. As I understand the SCSI error handling, thedevice_resetis only called ifabort_handlerfails to abort the command. What's an extra agent reset going to do then? And thesbp2.cabort_handleralways returns SUCCESS, btw.
That's of course bogus, and it is that way because I didn't take the time yet to clean this up. :-)
Quoted 3 lines
So unless we want to implement "abort task" (finer grained) or target reset/write
RESET_STARTtoSTATE_SET(coarser grained) it doesn't make sense to have more than one error handler callback.
Yes.
Quoted 2 lines
And since we have one SCSI host per fetch agent, it doesn't make much of a difference which error handler we implement.
There are differences, if you look at scsi_error.c. I'm just not sure at the moment how relevant these differences for sbp2/ fw-sbp2 are. (See below.)
Besides, one Scsi_Host per LU doesn't have to stay that way. It's just another thing which could be cleaned up.
Quoted 7 lines
Quoted 2 lines
The closest concept to "host bus adpaters" in SBP-2 are initiator ports, and there is no notion of resetting an SBP-2 initiator port.
Could a fetch agent not be viewed as a host bus adapter? The way I see it is that it has a set of registers that are available to the CPU through some bus. In this case the bus is IEEE1394 but it could be the PCI bus.
Forget the "host bus adapters" which are mentioned in Linux SCSI core. What are meant there are cards which connect SCSI Parallel Interconnect with a local bus. The stuff that Linux SCSI core does with its "host bus adapters" is stuff for SPI drivers. It's in the Linux SCSI core not because it belongs there but because nobody took it out of there. The other transport drivers besides SPI drivers take what Linux SCSI core's low-level API offers them and deal with it one way or another.
The SBP-2 fetch agent is part of the target. Talking to it by means of its registers and the initiator's status FIFO is part of an transport driver on initiator side. We talk to the fetch agent via the SCSI interconnect, which is the IEEE 1394 Serial Bus.
The target's fetch agents are _not_ elements between the SCSI interconnect and a local bus, like "host bus adapters" are.
Quoted 11 lines
Quoted 4 lines
But theoretic semantics aside: Check
drivers/scsi/scsi_error.cfor what comes after one or anotherhostt->eh_handler was called. Do you want the subsequent call toscsi_report_bus_reset()? Probably not. But perhaps you want what comes afterhostt->eh_device_reset_handlerwas called.This is the call chain:
if (__scsi_try_to_abort_cmd(scmd) != SUCCESS) if (scsi_try_bus_device_reset(scmd) != SUCCESS) if (scsi_try_bus_reset(scmd) != SUCCESS) scsi_try_host_reset(scmd);
Yes, and these stages do different things.
Quoted 1 line
We don't support aborting individual commands
Correct.
Quoted 1 line
or individual LUNs,
No. One scsi_device maps to one SBP-2 Logical Unit (LU). SBP-2 always deals only with individual LUs, except that a target's configuration ROM is first examined as a whole to discover LUs.
Quoted 1 line
and we're not doing a SCSI bus reset...
Correct, because a "SCSI bus reset" is something specific to SCSI Parallel Interconnect. The term "SCSI bus reset" implies "SCSI bus" == SCSI Parallel Interconnect.
Some other interconnects, for example the Serial Bus, define bus resets too. However, such bus resets play entirely different roles for the different transport protocols.
Quoted 2 lines
I dunno, I think the host reset seems appropriate, but I don't really know much about SCSI :)
_device_reset comes close to a fetch agent reset; but as I said I'm not sure about the rest which happens in scsi_try_bus_device_reset if hostt->eh_device_reset_handler(scmd) == SUCCESS.
The expecting_cc_ua bit becomes effective in scsi_error.c::scsi_check_sense:
http://lxr.free-electrons.com/source/drivers/scsi/scsi_error.c?v=2.6.20#329
I don't know yet what to make of it. Perhaps a kind reader at LSML can give further pointers.
The was_reset bit has ramifications for the st (tape) driver. That should be looked into too.
Signature · 7 lines
Stefan Richter -=====-=-=== -=-- -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 1 line · Stefan Richter
Kristian Høgsberg wrote:
...
Quoted 11 lines
Quoted 7 lines
Quoted 2 lines
The closest concept to "host bus adpaters" in SBP-2 are initiator ports, and there is no notion of resetting an SBP-2 initiator port.
Could a fetch agent not be viewed as a host bus adapter? The way I see it is that it has a set of registers that are available to the CPU through some bus. In this case the bus is IEEE1394 but it could be the PCI bus.
Forget the "host bus adapters" which are mentioned in Linux SCSI core. What are meant there are cards which connect SCSI Parallel Interconnect with a local bus.
Or maybe more generally bridge chipsets that connect SCSI Parallel interconnect with a non-SCSI, but not necessarily local, bus (PCI or IEEE1394)?
Quoted 6 lines
The stuff that Linux SCSI core does with its "host
bus adapters" is stuff for SPI drivers. It's in the Linux SCSI core not because it belongs there but because nobody took it out of there. The other transport drivers besides SPI drivers take what Linux SCSI core's low-level API offers them and deal with it one way or another.
Quoted 7 lines
The SBP-2 fetch agent is part of the target. Talking to it by means of its registers and the initiator's status FIFO is part of an transport driver on initiator side. We talk to the fetch agent via the SCSI interconnect, which is the IEEE 1394 Serial Bus.
The target's fetch agents are _not_ elements between the SCSI interconnect and a local bus, like "host bus adapters" are.
Why not though? I mean, IEEE1394 isn't a local bus, but other than that the architechture looks a lot like the PCI adaptor case.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
But theoretic semantics aside: Check
drivers/scsi/scsi_error.cfor what comes after one or anotherhostt->eh_handler was called. Do you want the subsequent call toscsi_report_bus_reset()? Probably not. But perhaps you want what comes afterhostt->eh_device_reset_handlerwas called.
Quoted 8 lines
Quoted 6 lines
This is the call chain:
if (__scsi_try_to_abort_cmd(scmd) != SUCCESS) if (scsi_try_bus_device_reset(scmd) != SUCCESS) if (scsi_try_bus_reset(scmd) != SUCCESS) scsi_try_host_reset(scmd);Yes, and these stages do different things.
Oh right... yeah, there are subtle differences in recovery depending on which of the error handlers succeed.
Quoted 9 lines
Quoted 1 line
We don't support aborting individual commands
Correct.
Quoted 1 line
or individual LUNs,
No. One
scsi_devicemaps to one SBP-2 Logical Unit (LU). SBP-2 always deals only with individual LUs, except that a target's configuration ROM is first examined as a whole to discover LUs.
Yeah, and that's broken. sbp2.c adds two scsi_hosts for each lun found but they both try to access the same fetch agent registers. There's no way that can work. In fw-sbp2.c I just don't support that yet (I have no devices that have that configuration), but I want to add both LUNs to the same scsi_host, because that's the only thing that can work.
SBP-2 (the protocol) has a task management request for resetting a LUN which could be used for device_reset in this situation.
Quoted 9 lines
Quoted 1 line
and we're not doing a SCSI bus reset...
Correct, because a "SCSI bus reset" is something specific to SCSI Parallel Interconnect. The term "SCSI bus reset" implies "SCSI bus" == SCSI Parallel Interconnect.
Some other interconnects, for example the Serial Bus, define bus resets too. However, such bus resets play entirely different roles for the different transport protocols.
Yup, different buses, different types of resets.
Quoted 6 lines
Quoted 2 lines
I dunno, I think the host reset seems appropriate, but I don't really know much about SCSI :)
_device_resetcomes close to a fetch agent reset; but as I said I'm not sure about the rest which happens inscsi_try_bus_device_resetifhostt->eh_device_reset_handler(scmd)== SUCCESS.
Well, fetch agent resets all the LUNs controlled by the fetch agents, and thus has a broader scope than just device_reset.
cheers,
Kristian
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
Quoted 8 lines · Kristian Høgsberg
On 4/11/07, Stefan Richter <[email protected]> wrote:
Forget the "host bus adapters" which are mentioned in Linux SCSI core.Quoted 2 lines
What are meant there are cards which connect SCSI Parallel Interconnect with a local bus.
Or maybe more generally bridge chipsets that connect SCSI Parallel interconnect with a non-SCSI, but not necessarily local, bus (PCI or IEEE1394)?
No. Those "host bus adapters" are "initiator-internal bus to SPI adapter cards". They have little to nothing to do with the various non-SPI incarnations of the SCSI Architecture Model.
Quoted 5 lines
Quoted 2 lines
The target's fetch agents are _not_ elements between the SCSI interconnect and a local bus, like "host bus adapters" are.
Why not though? I mean, IEEE1394 isn't a local bus, but other than that the architechture looks a lot like the PCI adaptor case.
The SBP-2 fetch agent is an target-side element at the transport level.
It is neither part of the initiator, nor does it implement
functionality at the interconnect level.
Quoted 7 lines
Quoted 3 lines
One
scsi_devicemaps to one SBP-2 Logical Unit (LU). SBP-2 always deals only with individual LUs, except that a target's configuration ROM is first examined as a whole to discover LUs.Yeah, and that's broken.
sbp2.cadds twoscsi_hostsfor each lun found but they both try to access the same fetch agent registers. There's no way that can work.
I don't follow you.
- It's correct to instantiate one scsi_device for each SCSI Logical Unit.
- sbp2 instantiates one Scsi_Host for each scsi_device. That's awkward but not incorrect. (The target dosn't know, initiator-side side command set layer doesn't care, and initiator-side application clients have to put up with it. For the latter, it would be nice if Scsi_Host had a well-defined meaning for all transports, e.g. the meaning of a SCSI Initiator Port. But it doesn't.)
- sbp2 logs in to each SCSI Logical Unit separately, and talks to the command block agent CSRs it is pointed to by the respective login responses. (By necessity, each LU has a separate area of command block agent registers.)
What's wrong with that?
I have a dual LU SBP-2 to IDE bridge which is fully supported by sbp2. I haven't checked though if it poses as a node with one SCSI target with two LUs, or as a node with two SCSI targets with one LU each. It does contain only a single 1394 link and IDE controller though.
(BTW, I'm saying LU all the time because LUN means Logical Unit Number and is merely something used to identify a LU.)
Quoted 4 lines
In
fw-sbp2.cI just don't support that
yet (I have no devices that have that configuration), but I want to add both LUNs to the samescsi_host, because that's the only thing that can work.
No, it's doesn't make a difference if LUs of the same target hang on different instances of Scsi_Host, except that application clients can't figure out in a transport-agnostic way that the LUs belong to the same target. But to correct that, (1.) all LUs of the same target have to be added to the same scsi_target or whatever Linux SCSI core artifact is meant to represent a target, or/and (2.) SAM compliant target identifiers etc. had to be supported by the Linux SCSI core.
Quoted 2 lines
SBP-2 (the protocol) has a task management request for resetting a LUN which could be used for
device_resetin this situation.
Yes; we should look into whether that's useful together with more than one implemented level of .eh callbacks. What we have so far only issues ABORT TASK SET; what we could add is LOGICAL UNIT RESET (but SBP-2 targets are not required to support that) and TARGET RESET (which would be the bigger hammer onto all LUs of a target). The Linux SCSI core however doesn't support the notion of task management functions; it's up to implementers of transport layer drivers to figure out which TMF to do when.
LOGICAL UNIT RESET does not look appropriate for scsi_try_bus_device_reset though, because LOGICAL UNIT RESET will not cause a unit attention condition for the initiator who requested the reset.
...
Quoted 1 line
Quoted 1 line
_device_resetcomes close to a fetch agent reset;
Or rather not, because expecting_cc_ua should apparently be left off after a fetch agent reset.
Quoted 3 lines
Quoted 3 lines
but as I said I'm not
sure about the rest which happens inscsi_try_bus_device_resetifhostt->eh_device_reset_handler(scmd)== SUCCESS.
(I meant I'm not sure about what scsi_error.c does, and I still am not sure. :-)
Quoted 2 lines
Well, fetch agent resets all the LUNs controlled by the fetch agents, and thus has a broader scope than just
device_reset.
That would be true for a TARGET RESET, but not for any of the other TMFs. Particularly, fetch agent reset affects the state of only one LU; the one to which the command block agent registers belong to.
Signature · 9 lines
Stefan Richter -=====-=-=== -=-- -=-== http://arcgraph.de/sr/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV