I wrote: > Kristian Høgsberg wrote: >> 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". ... > 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. 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 -- Stefan Richter -=====-=-=== -=-- -=-== http://arcgraph.de/sr/ - To unsubscribe from this list: 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
