On 08/18/2009 11:42 AM, Mike Christie wrote:
>
> So my proposal is to just wait for the tasks that are queued and
> affected by the TMF to get fully sent. Note, at this time, we do not
> allow new commands that could be affected by the TMF to be started.
>
> The eh thread sits around and every seco
On 08/14/2009 08:08 AM, Hannes Reinecke wrote:
> Ulrich Windl wrote:
>> On 13 Aug 2009 at 11:55, Mike Christie wrote:
>>
>>> some additions:
>>>
>>>
>>> Mike Christie wrote:
wait_on_commands()
{
>>> while (check_restrictions(conn->task)&&
>>> session->state == LOGGED_IN)
On 08/17/2009 01:31 AM, Ulrich Windl wrote:
> On 14 Aug 2009 at 15:08, Hannes Reinecke wrote:
>
>> Ulrich Windl wrote:
>>> On 13 Aug 2009 at 11:55, Mike Christie wrote:
>>>
some additions:
Mike Christie wrote:
> wait_on_commands()
> {
while (check_restrictions(c
On 14 Aug 2009 at 15:08, Hannes Reinecke wrote:
>
> Ulrich Windl wrote:
> > On 13 Aug 2009 at 11:55, Mike Christie wrote:
> >
> >> some additions:
> >>
> >>
> >> Mike Christie wrote:
> >>> wait_on_commands()
> >>> {
> >>while (check_restrictions(conn->task) &&
> >>session->state
Ulrich Windl wrote:
> On 13 Aug 2009 at 11:55, Mike Christie wrote:
>
>> some additions:
>>
>>
>> Mike Christie wrote:
>>> wait_on_commands()
>>> {
>> while (check_restrictions(conn->task) &&
>> session->state == LOGGED_IN)
>> wait for a while
>
> "wait for a while
On 13 Aug 2009 at 11:55, Mike Christie wrote:
>
> some additions:
>
>
> Mike Christie wrote:
> > wait_on_commands()
> > {
> while (check_restrictions(conn->task) &&
> session->state == LOGGED_IN)
> wait for a while
"wait for a while" always looks like a desig
Mike Christie wrote:
> Hannes Reinecke wrote:
>> If 'fast_abort' is not set we should be sending all outstanding
>> Data-out PDUs to the target, even after we have received the
>> tmf response. So we should make sure that the workqueue is really
>> flushed and all PDUs have been processed before s
Mike Christie wrote:
> some additions:
>
Ugh, sorry, one more change. If iscsi recovery kicks in due to a logout,
iscsi/conn error or someone just tryiing to shutdown the session then we
could be calling the ep_disconnect code or conn stop.
>
> Mike Christie wrote:
>> wait_on_commands()
>> {
some additions:
Mike Christie wrote:
> wait_on_commands()
> {
while (check_restrictions(conn->task) &&
session->state == LOGGED_IN)
wait for a while
> loop for each cmd on requeue list
if (session->state != LOGGED_IN)
Hannes Reinecke wrote:
>
> If 'fast_abort' is not set we should be sending all outstanding
> Data-out PDUs to the target, even after we have received the
> tmf response. So we should make sure that the workqueue is really
> flushed and all PDUs have been processed before setting the
> 'SUSPEND' b
If 'fast_abort' is not set we should be sending all outstanding
Data-out PDUs to the target, even after we have received the
tmf response. So we should make sure that the workqueue is really
flushed and all PDUs have been processed before setting the
'SUSPEND' bit.
Signed-off-by: Hannes Reinecke
11 matches
Mail list logo
