An attempt to solve several issues that have been annoying me for some time,

namely double panics when saving the dump (related to bus reset/command aborts),

panics when constantly inquiring the targets on bus configs, and simple some

cleanup:

don't abort commands before resetting the bus (called from sddump), leading

  to processing already freed ones
rework the command abort path - follow what linux does, and sleep for a bit of

  time waiting for command abort to be acknowledged by HBA
cleanup the poll code path
rework comp ring processing - only check the completion ring in interrupt,

  leaving everything else to be done using the taskq; complete commands as we

  get them from the ring, without chaining them and processing later - this

  came with initial driver version, and I don't have any idea why it was done

  as it doesn't show any performance gains (which is exactly what could be

  expected)
rework msg ring processing (triggered by Robert's questions) - only check

  the message ring in interrupt handler, leaving everything else to be done

  using the taskq; this way we won't ever miss a notification - if taskq

  dispatch fails, the message ring is left untouched
introduce a static "target map" instead of dynamically allocated one, don't

  do inquiry every time when the bus config happens, and instead rely on target

  map to report if target is already attached, as it can't simply disappear

  without a notification (virtual hardware is a "perfect world", or should be)

All done using the disks connected via this driver, or on a pool on top of them:

- zfs-tests run

- full nightly build

- continuos vdbench runs

- bulk add/remove the disks (under the load as well)