scsi_eh.txt 17 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493
  1. SCSI EH
  2. ======================================
  3. This document describes SCSI midlayer error handling infrastructure.
  4. Please refer to Documentation/scsi/scsi_mid_low_api.txt for more
  5. information regarding SCSI midlayer.
  6. TABLE OF CONTENTS
  7. [1] How SCSI commands travel through the midlayer and to EH
  8. [1-1] struct scsi_cmnd
  9. [1-2] How do scmd's get completed?
  10. [1-2-1] Completing a scmd w/ scsi_done
  11. [1-2-2] Completing a scmd w/ timeout
  12. [1-3] How EH takes over
  13. [2] How SCSI EH works
  14. [2-1] EH through fine-grained callbacks
  15. [2-1-1] Overview
  16. [2-1-2] Flow of scmds through EH
  17. [2-1-3] Flow of control
  18. [2-2] EH through transportt->eh_strategy_handler()
  19. [2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
  20. [2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
  21. [2-2-3] Things to consider
  22. [1] How SCSI commands travel through the midlayer and to EH
  23. [1-1] struct scsi_cmnd
  24. Each SCSI command is represented with struct scsi_cmnd (== scmd). A
  25. scmd has two list_head's to link itself into lists. The two are
  26. scmd->list and scmd->eh_entry. The former is used for free list or
  27. per-device allocated scmd list and not of much interest to this EH
  28. discussion. The latter is used for completion and EH lists and unless
  29. otherwise stated scmds are always linked using scmd->eh_entry in this
  30. discussion.
  31. [1-2] How do scmd's get completed?
  32. Once LLDD gets hold of a scmd, either the LLDD will complete the
  33. command by calling scsi_done callback passed from midlayer when
  34. invoking hostt->queuecommand() or the block layer will time it out.
  35. [1-2-1] Completing a scmd w/ scsi_done
  36. For all non-EH commands, scsi_done() is the completion callback. It
  37. just calls blk_complete_request() to delete the block layer timer and
  38. raise SCSI_SOFTIRQ
  39. SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to
  40. determine what to do with the command. scsi_decide_disposition()
  41. looks at the scmd->result value and sense data to determine what to do
  42. with the command.
  43. - SUCCESS
  44. scsi_finish_command() is invoked for the command. The
  45. function does some maintenance chores and then calls
  46. scsi_io_completion() to finish the I/O.
  47. scsi_io_completion() then notifies the block layer on
  48. the completed request by calling blk_end_request and
  49. friends or figures out what to do with the remainder
  50. of the data in case of an error.
  51. - NEEDS_RETRY
  52. - ADD_TO_MLQUEUE
  53. scmd is requeued to blk queue.
  54. - otherwise
  55. scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
  56. [1-3] for details of this function.
  57. [1-2-2] Completing a scmd w/ timeout
  58. The timeout handler is scsi_times_out(). When a timeout occurs, this
  59. function
  60. 1. invokes optional hostt->eh_timed_out() callback. Return value can
  61. be one of
  62. - BLK_EH_HANDLED
  63. This indicates that eh_timed_out() dealt with the timeout.
  64. The command is passed back to the block layer and completed
  65. via __blk_complete_requests().
  66. *NOTE* After returning BLK_EH_HANDLED the SCSI layer is
  67. assumed to be finished with the command, and no other
  68. functions from the SCSI layer will be called. So this
  69. should typically only be returned if the eh_timed_out()
  70. handler raced with normal completion.
  71. - BLK_EH_RESET_TIMER
  72. This indicates that more time is required to finish the
  73. command. Timer is restarted. This action is counted as a
  74. retry and only allowed scmd->allowed + 1(!) times. Once the
  75. limit is reached, action for BLK_EH_NOT_HANDLED is taken instead.
  76. - BLK_EH_NOT_HANDLED
  77. eh_timed_out() callback did not handle the command.
  78. Step #2 is taken.
  79. 2. If the host supports asynchronous completion (as indicated by the
  80. no_async_abort setting in the host template) scsi_abort_command()
  81. is invoked to schedule an asynchrous abort. If that fails
  82. Step #3 is taken.
  83. 2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the
  84. command. See [1-3] for more information.
  85. [1-3] Asynchronous command aborts
  86. After a timeout occurs a command abort is scheduled from
  87. scsi_abort_command(). If the abort is successful the command
  88. will either be retried (if the number of retries is not exhausted)
  89. or terminated with DID_TIME_OUT.
  90. Otherwise scsi_eh_scmd_add() is invoked for the command.
  91. See [1-4] for more information.
  92. [1-4] How EH takes over
  93. scmds enter EH via scsi_eh_scmd_add(), which does the following.
  94. 1. Turns on scmd->eh_eflags as requested. It's 0 for error
  95. completions and SCSI_EH_CANCEL_CMD for timeouts.
  96. 2. Links scmd->eh_entry to shost->eh_cmd_q
  97. 3. Sets SHOST_RECOVERY bit in shost->shost_state
  98. 4. Increments shost->host_failed
  99. 5. Wakes up SCSI EH thread if shost->host_busy == shost->host_failed
  100. As can be seen above, once any scmd is added to shost->eh_cmd_q,
  101. SHOST_RECOVERY shost_state bit is turned on. This prevents any new
  102. scmd to be issued from blk queue to the host; eventually, all scmds on
  103. the host either complete normally, fail and get added to eh_cmd_q, or
  104. time out and get added to shost->eh_cmd_q.
  105. If all scmds either complete or fail, the number of in-flight scmds
  106. becomes equal to the number of failed scmds - i.e. shost->host_busy ==
  107. shost->host_failed. This wakes up SCSI EH thread. So, once woken up,
  108. SCSI EH thread can expect that all in-flight commands have failed and
  109. are linked on shost->eh_cmd_q.
  110. Note that this does not mean lower layers are quiescent. If a LLDD
  111. completed a scmd with error status, the LLDD and lower layers are
  112. assumed to forget about the scmd at that point. However, if a scmd
  113. has timed out, unless hostt->eh_timed_out() made lower layers forget
  114. about the scmd, which currently no LLDD does, the command is still
  115. active as long as lower layers are concerned and completion could
  116. occur at any time. Of course, all such completions are ignored as the
  117. timer has already expired.
  118. We'll talk about how SCSI EH takes actions to abort - make LLDD
  119. forget about - timed out scmds later.
  120. [2] How SCSI EH works
  121. LLDD's can implement SCSI EH actions in one of the following two
  122. ways.
  123. - Fine-grained EH callbacks
  124. LLDD can implement fine-grained EH callbacks and let SCSI
  125. midlayer drive error handling and call appropriate callbacks.
  126. This will be discussed further in [2-1].
  127. - eh_strategy_handler() callback
  128. This is one big callback which should perform whole error
  129. handling. As such, it should do all chores the SCSI midlayer
  130. performs during recovery. This will be discussed in [2-2].
  131. Once recovery is complete, SCSI EH resumes normal operation by
  132. calling scsi_restart_operations(), which
  133. 1. Checks if door locking is needed and locks door.
  134. 2. Clears SHOST_RECOVERY shost_state bit
  135. 3. Wakes up waiters on shost->host_wait. This occurs if someone
  136. calls scsi_block_when_processing_errors() on the host.
  137. (*QUESTION* why is it needed? All operations will be blocked
  138. anyway after it reaches blk queue.)
  139. 4. Kicks queues in all devices on the host in the asses
  140. [2-1] EH through fine-grained callbacks
  141. [2-1-1] Overview
  142. If eh_strategy_handler() is not present, SCSI midlayer takes charge
  143. of driving error handling. EH's goals are two - make LLDD, host and
  144. device forget about timed out scmds and make them ready for new
  145. commands. A scmd is said to be recovered if the scmd is forgotten by
  146. lower layers and lower layers are ready to process or fail the scmd
  147. again.
  148. To achieve these goals, EH performs recovery actions with increasing
  149. severity. Some actions are performed by issuing SCSI commands and
  150. others are performed by invoking one of the following fine-grained
  151. hostt EH callbacks. Callbacks may be omitted and omitted ones are
  152. considered to fail always.
  153. int (* eh_abort_handler)(struct scsi_cmnd *);
  154. int (* eh_device_reset_handler)(struct scsi_cmnd *);
  155. int (* eh_bus_reset_handler)(struct scsi_cmnd *);
  156. int (* eh_host_reset_handler)(struct scsi_cmnd *);
  157. Higher-severity actions are taken only when lower-severity actions
  158. cannot recover some of failed scmds. Also, note that failure of the
  159. highest-severity action means EH failure and results in offlining of
  160. all unrecovered devices.
  161. During recovery, the following rules are followed
  162. - Recovery actions are performed on failed scmds on the to do list,
  163. eh_work_q. If a recovery action succeeds for a scmd, recovered
  164. scmds are removed from eh_work_q.
  165. Note that single recovery action on a scmd can recover multiple
  166. scmds. e.g. resetting a device recovers all failed scmds on the
  167. device.
  168. - Higher severity actions are taken iff eh_work_q is not empty after
  169. lower severity actions are complete.
  170. - EH reuses failed scmds to issue commands for recovery. For
  171. timed-out scmds, SCSI EH ensures that LLDD forgets about a scmd
  172. before reusing it for EH commands.
  173. When a scmd is recovered, the scmd is moved from eh_work_q to EH
  174. local eh_done_q using scsi_eh_finish_cmd(). After all scmds are
  175. recovered (eh_work_q is empty), scsi_eh_flush_done_q() is invoked to
  176. either retry or error-finish (notify upper layer of failure) recovered
  177. scmds.
  178. scmds are retried iff its sdev is still online (not offlined during
  179. EH), REQ_FAILFAST is not set and ++scmd->retries is less than
  180. scmd->allowed.
  181. [2-1-2] Flow of scmds through EH
  182. 1. Error completion / time out
  183. ACTION: scsi_eh_scmd_add() is invoked for scmd
  184. - set scmd->eh_eflags
  185. - add scmd to shost->eh_cmd_q
  186. - set SHOST_RECOVERY
  187. - shost->host_failed++
  188. LOCKING: shost->host_lock
  189. 2. EH starts
  190. ACTION: move all scmds to EH's local eh_work_q. shost->eh_cmd_q
  191. is cleared.
  192. LOCKING: shost->host_lock (not strictly necessary, just for
  193. consistency)
  194. 3. scmd recovered
  195. ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd
  196. - clear scmd->eh_eflags
  197. - scsi_setup_cmd_retry()
  198. - move from local eh_work_q to local eh_done_q
  199. LOCKING: none
  200. CONCURRENCY: at most one thread per separate eh_work_q to
  201. keep queue manipulation lockless
  202. 4. EH completes
  203. ACTION: scsi_eh_flush_done_q() retries scmds or notifies upper
  204. layer of failure. May be called concurrently but must have
  205. a no more than one thread per separate eh_work_q to
  206. manipulate the queue locklessly
  207. - scmd is removed from eh_done_q and scmd->eh_entry is cleared
  208. - if retry is necessary, scmd is requeued using
  209. scsi_queue_insert()
  210. - otherwise, scsi_finish_command() is invoked for scmd
  211. - zero shost->host_failed
  212. LOCKING: queue or finish function performs appropriate locking
  213. [2-1-3] Flow of control
  214. EH through fine-grained callbacks start from scsi_unjam_host().
  215. <<scsi_unjam_host>>
  216. 1. Lock shost->host_lock, splice_init shost->eh_cmd_q into local
  217. eh_work_q and unlock host_lock. Note that shost->eh_cmd_q is
  218. cleared by this action.
  219. 2. Invoke scsi_eh_get_sense.
  220. <<scsi_eh_get_sense>>
  221. This action is taken for each error-completed
  222. (!SCSI_EH_CANCEL_CMD) commands without valid sense data. Most
  223. SCSI transports/LLDDs automatically acquire sense data on
  224. command failures (autosense). Autosense is recommended for
  225. performance reasons and as sense information could get out of
  226. sync between occurrence of CHECK CONDITION and this action.
  227. Note that if autosense is not supported, scmd->sense_buffer
  228. contains invalid sense data when error-completing the scmd
  229. with scsi_done(). scsi_decide_disposition() always returns
  230. FAILED in such cases thus invoking SCSI EH. When the scmd
  231. reaches here, sense data is acquired and
  232. scsi_decide_disposition() is called again.
  233. 1. Invoke scsi_request_sense() which issues REQUEST_SENSE
  234. command. If fails, no action. Note that taking no action
  235. causes higher-severity recovery to be taken for the scmd.
  236. 2. Invoke scsi_decide_disposition() on the scmd
  237. - SUCCESS
  238. scmd->retries is set to scmd->allowed preventing
  239. scsi_eh_flush_done_q() from retrying the scmd and
  240. scsi_eh_finish_cmd() is invoked.
  241. - NEEDS_RETRY
  242. scsi_eh_finish_cmd() invoked
  243. - otherwise
  244. No action.
  245. 3. If !list_empty(&eh_work_q), invoke scsi_eh_abort_cmds().
  246. <<scsi_eh_abort_cmds>>
  247. This action is taken for each timed out command when
  248. no_async_abort is enabled in the host template.
  249. hostt->eh_abort_handler() is invoked for each scmd. The
  250. handler returns SUCCESS if it has succeeded to make LLDD and
  251. all related hardware forget about the scmd.
  252. If a timedout scmd is successfully aborted and the sdev is
  253. either offline or ready, scsi_eh_finish_cmd() is invoked for
  254. the scmd. Otherwise, the scmd is left in eh_work_q for
  255. higher-severity actions.
  256. Note that both offline and ready status mean that the sdev is
  257. ready to process new scmds, where processing also implies
  258. immediate failing; thus, if a sdev is in one of the two
  259. states, no further recovery action is needed.
  260. Device readiness is tested using scsi_eh_tur() which issues
  261. TEST_UNIT_READY command. Note that the scmd must have been
  262. aborted successfully before reusing it for TEST_UNIT_READY.
  263. 4. If !list_empty(&eh_work_q), invoke scsi_eh_ready_devs()
  264. <<scsi_eh_ready_devs>>
  265. This function takes four increasingly more severe measures to
  266. make failed sdevs ready for new commands.
  267. 1. Invoke scsi_eh_stu()
  268. <<scsi_eh_stu>>
  269. For each sdev which has failed scmds with valid sense data
  270. of which scsi_check_sense()'s verdict is FAILED,
  271. START_STOP_UNIT command is issued w/ start=1. Note that
  272. as we explicitly choose error-completed scmds, it is known
  273. that lower layers have forgotten about the scmd and we can
  274. reuse it for STU.
  275. If STU succeeds and the sdev is either offline or ready,
  276. all failed scmds on the sdev are EH-finished with
  277. scsi_eh_finish_cmd().
  278. *NOTE* If hostt->eh_abort_handler() isn't implemented or
  279. failed, we may still have timed out scmds at this point
  280. and STU doesn't make lower layers forget about those
  281. scmds. Yet, this function EH-finish all scmds on the sdev
  282. if STU succeeds leaving lower layers in an inconsistent
  283. state. It seems that STU action should be taken only when
  284. a sdev has no timed out scmd.
  285. 2. If !list_empty(&eh_work_q), invoke scsi_eh_bus_device_reset().
  286. <<scsi_eh_bus_device_reset>>
  287. This action is very similar to scsi_eh_stu() except that,
  288. instead of issuing STU, hostt->eh_device_reset_handler()
  289. is used. Also, as we're not issuing SCSI commands and
  290. resetting clears all scmds on the sdev, there is no need
  291. to choose error-completed scmds.
  292. 3. If !list_empty(&eh_work_q), invoke scsi_eh_bus_reset()
  293. <<scsi_eh_bus_reset>>
  294. hostt->eh_bus_reset_handler() is invoked for each channel
  295. with failed scmds. If bus reset succeeds, all failed
  296. scmds on all ready or offline sdevs on the channel are
  297. EH-finished.
  298. 4. If !list_empty(&eh_work_q), invoke scsi_eh_host_reset()
  299. <<scsi_eh_host_reset>>
  300. This is the last resort. hostt->eh_host_reset_handler()
  301. is invoked. If host reset succeeds, all failed scmds on
  302. all ready or offline sdevs on the host are EH-finished.
  303. 5. If !list_empty(&eh_work_q), invoke scsi_eh_offline_sdevs()
  304. <<scsi_eh_offline_sdevs>>
  305. Take all sdevs which still have unrecovered scmds offline
  306. and EH-finish the scmds.
  307. 5. Invoke scsi_eh_flush_done_q().
  308. <<scsi_eh_flush_done_q>>
  309. At this point all scmds are recovered (or given up) and
  310. put on eh_done_q by scsi_eh_finish_cmd(). This function
  311. flushes eh_done_q by either retrying or notifying upper
  312. layer of failure of the scmds.
  313. [2-2] EH through transportt->eh_strategy_handler()
  314. transportt->eh_strategy_handler() is invoked in the place of
  315. scsi_unjam_host() and it is responsible for whole recovery process.
  316. On completion, the handler should have made lower layers forget about
  317. all failed scmds and either ready for new commands or offline. Also,
  318. it should perform SCSI EH maintenance chores to maintain integrity of
  319. SCSI midlayer. IOW, of the steps described in [2-1-2], all steps
  320. except for #1 must be implemented by eh_strategy_handler().
  321. [2-2-1] Pre transportt->eh_strategy_handler() SCSI midlayer conditions
  322. The following conditions are true on entry to the handler.
  323. - Each failed scmd's eh_flags field is set appropriately.
  324. - Each failed scmd is linked on scmd->eh_cmd_q by scmd->eh_entry.
  325. - SHOST_RECOVERY is set.
  326. - shost->host_failed == shost->host_busy
  327. [2-2-2] Post transportt->eh_strategy_handler() SCSI midlayer conditions
  328. The following conditions must be true on exit from the handler.
  329. - shost->host_failed is zero.
  330. - Each scmd's eh_eflags field is cleared.
  331. - Each scmd is in such a state that scsi_setup_cmd_retry() on the
  332. scmd doesn't make any difference.
  333. - shost->eh_cmd_q is cleared.
  334. - Each scmd->eh_entry is cleared.
  335. - Either scsi_queue_insert() or scsi_finish_command() is called on
  336. each scmd. Note that the handler is free to use scmd->retries and
  337. ->allowed to limit the number of retries.
  338. [2-2-3] Things to consider
  339. - Know that timed out scmds are still active on lower layers. Make
  340. lower layers forget about them before doing anything else with
  341. those scmds.
  342. - For consistency, when accessing/modifying shost data structure,
  343. grab shost->host_lock.
  344. - On completion, each failed sdev must have forgotten about all
  345. active scmds.
  346. - On completion, each failed sdev must be ready for new commands or
  347. offline.
  348. --
  349. Tejun Heo
  350. htejun@gmail.com
  351. 11th September 2005