Simone Morellato wrote: > Hi Mike, > > I changed the timeouts in the open-iscsi conf file > node.session.timeo.replacement_timeout - changed from the 120 > default) to 0 > node.session.initial_login_retry_max - changed from 4 (default) to 40. > > With these changes open-iscsi initiator logs back in but the session > State is not correct and we could not send any I/O's over it. > > before deleting target >> iSCSI Connection State: LOGGED IN >> iSCSI Session State: LOGGED_IN >> Internal iscsid Session State: NO CHANGE >> >> after target deleted >> iSCSI Connection State: TRANSPORT WAIT >> iSCSI Session State: FREE >> Internal iscsid Session State: REPOEN > > Does this tell you anything? >
Something is horribly wrong. The node.session.timeo.replacement_timeout does not come into play here really. It just deals with when we fail SCSI IO in the kernel. If setting node.session.initial_login_retry_max works that could mean the state machine is out of wack which makes sense if you see >> iSCSI Connection State: TRANSPORT WAIT >> iSCSI Session State: FREE >> Internal iscsid Session State: REPOEN and you are logged back in. There also was a code change in that path in the 870 release. How do you know you are logged back in btw? Do you see this on the target side? For some reason in the ethereal traces I cannot see the iscsi packets. Is there any argument I have to run wireshark with? If you could send the iscsid log with -d 8, it would be helpful. With that I should hopefully see where iscsid is taking a bad turn. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
