On Sat, Sep 24, 2011 at 3:18 AM, Mike Christie <[email protected]> wrote:
> On 09/23/2011 02:43 AM, Vivek S wrote: > > Hi, > > > > iscsi session recovery work is queued by function __iscsi_block_session > > which is in turn called by iscsi_block_session. > > > > This is the function call sequence i figured out (using sw iscsi over > > tcp/ip) > > > > iscsi_if_recv_msg (ISCSI_UEVENT_STOP_CONN) -> iscsi_sw_tcp_conn_stop -> > > iscsi_conn_stop -> iscsi_start_session_recovery -> iscsi_block_session > > > > This means that the session recovery work is initiated by the user space. > > What events propageted to user space causes it to initiate this recovery > ? A > > function call sequence would greatly help. > > > > I think it was just userspace controlled recovery, so if we ended doing > other ERLs then iscsid might decided to do something else and that > smarts was going to be all in userspace. > > What is ERL ? > Also, we have to sleep in that iscsi_start_session_recovery path so we > cannot always call it directly from the code path that we discovery the > problem from. A lot of times we could be in soft irq context (timer, > network soft irq, bottom half for other drivers). > > Why do we have sleep in iscsi_start_session_recovery ? > iscsi_block_session is actually called directly from the kernel for > qla4xxx in some cases. It is called from isr context in some places. > This is why it is queued to a thread. > > Its (recovery work) queued to a thread because the kernel or the isr cannot wait till the recovery work is completed. Is this correct ? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
