nHung dt processes are oftentimes encountered during perturbation (disruptive) type tests (failovers, panics,
etc).
nUsually this is the result of an I/O stack (driver), adapter firmware, switch, and/or storage issue.
nNormally dt will be hung in some system call, e.g. open(), read(), write(), fsync(), etc.
nDepending on the OS, either the kernel debugger or user level debugger can be used to report dt’s stack
trace.
nIn lieu of a stack trace, forcing a system crash to send the OS vendor for analysis is usually necessary and
required.
nGather OS error
logs, switch logs, storage logs, etc.
nUse dt’s no I/O
progress feature to trigger an analyzer.
n