On Wed, Sep 9, 2009 at 8:38 PM, Vladislav Bolkhovitin <v...@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. _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
