| | | 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
|
| ~ | | - cleanup the poll code path
|
| ~ | | - reduce the locking done before processing the completion ring - what was
|
| ~ | | previously the rx_mutex, as it only protects the access to completion ring,
|
| ~ | | rename it and lock/unlock in pvscsi_process_comp_ring() itself
|
| | ~ | - 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)
|
| - | | - 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 (yes, virtual hardware is a "perfect world") |
| - | |
|
| - | | Note that the command aborts are still quite unreliable, and need to be looked
|
| - | | at - linux driver does them much cleaner, but that requires some kernel
|
| - | | interfaces we don't have (or I'm not aware of them yet). |
