On Wed, Sep 9, 2009 at 12:29 AM, Chris Worley <[email protected]> wrote: > [ ... ] > But, the same issue occurs... the apps on the initiator hang, and the > target thinks all is well. An app will hang in one of the file > systems... the others seem to be working well (even though they are > comprised of the same drives as the hung fs/app), for example: you can > do a "find ." from their root w/o hanging "find", but if you try that > in the fs where the app is hung, "find" will hang. Lvscan/pvscan will > hang too. > > Strangely, restarting the target (removing ib_srpd and scst_vdisk > modules, then re-registering the disks with scst_vdisk and > re-modprobing ib_srpt from scratch) causes the apps on the initiator > to un-hang and make progress again... (but eventually hang again... > seemingly more readily than before). > > While nothing other than the messages you'd expect (from > re-registering the drives to the initiator logging in) occur on the > target, the initiator has much to say during this re-registration > period, starting w/ the time-out (that has been shown previously): > > Sep 8 22:04:07 nameme kernel: sd 30:0:0:3: timing out command, waited 360s > Sep 8 22:04:07 nameme kernel: sd 30:0:0:3: SCSI error: return code = > 0x06000000 > Sep 8 22:04:07 nameme kernel: end_request: I/O error, dev sdo, sector > 45304704 > [ ... ]
Hello Chris, Unless you will report the opposite I assume that the above issue (SRP timeouts) has been solved by the solution I sent you via private e-mail, namely to load the SRPT kernel module with the parameter 'thread' set to one (modprobe ib_srpt thread=1). Bart. _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
