[Scst-devel] [ofa-general] WinOF_2_0_5/SRP initiator: slow reads and eventually hangs

[Bart Van Assche]

On Wed, Sep 9, 2009 at 8:38 PM, Vladislav Bolkhovitin <vst at vlnb.net> wrote:
> Chris Worley, on 09/09/2009 02:29 AM wrote:
>> [ ... ]
>> Sep  8 22:40:39 nameme kernel: end_request: I/O error, dev sde, sector
>> 123559464
>> Sep  8 22:40:39 nameme kernel: device-mapper: multipath: Failing path
>> 8:64.
>> Sep  8 22:41:32 nameme kernel:  host27: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:32 nameme kernel:  host28: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:32 nameme kernel:  host29: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:32 nameme kernel:  host30: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:32 nameme kernel:  host31: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:32 nameme kernel:  host32: ib_srp: DREQ received -
>> connection closed
>> Sep  8 22:41:34 nameme kernel:  host27: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host27: add qp_in_err timer
>> Sep  8 22:41:34 nameme kernel:  host28: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host28: add qp_in_err timer
>> Sep  8 22:41:34 nameme kernel:  host29: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host29: add qp_in_err timer
>> Sep  8 22:41:34 nameme kernel:  host30: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host30: add qp_in_err timer
>> Sep  8 22:41:34 nameme kernel:  host31: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host31: add qp_in_err timer
>> Sep  8 22:41:34 nameme kernel:  host32: ib_srp: connection closed
>> Sep  8 22:41:34 nameme kernel: ib_srp:  host32: add qp_in_err timer
>> Sep  8 22:41:59 nameme kernel:  host27: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host27: ib_srp: srp_qp_in_err_timer
>> flushed reset - done
>> Sep  8 22:41:59 nameme kernel:  host28: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host28: ib_srp: srp_qp_in_err_timer
>> flushed reset - done
>> Sep  8 22:41:59 nameme kernel:  host29: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host29: ib_srp: srp_qp_in_err_timer
>> flushed reset - done
>> Sep  8 22:41:59 nameme kernel:  host30: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host30: ib_srp: srp_qp_in_err_timer
>> flushed reset - done
>> Sep  8 22:41:59 nameme kernel:  host31: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host31: ib_srp: srp_qp_in_err_timer
>> flushed reset - done
>> Sep  8 22:41:59 nameme kernel:  host32: ib_srp: srp_qp_in_err_timer called
>> Sep  8 22:41:59 nameme kernel:  host32: ib_srp: srp_qp_in_err_timer
>
> Those messages should be analyzed and can be a key.

The above messages mean that the SRP initiator correctly detected that
the SRP target closed six SRP connections. But how did you get six SRP
connections ? Are there six HCA's in the target system or are there
six different target systems ? And how has the device mapper been
configured on the initiator ?

Bart.