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

[Chris Worley]

On Sat, Sep 12, 2009 at 2:18 PM, Bart Van
Assche<bart.vanassche at gmail.com> wrote:
> 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 ?

The only thing there were six of are LVM volumes.  One HCA, using both
ports; 10 target drives being exported from one target.

Chris
>
> Bart.
>