[stgt] tgt reset on simple simulator

[Alexander Nezhinsky]

On Thu, Jun 13, 2013 at 11:55 AM, osishkin osishkin <osishkin at gmail.com> wrote:

> My part of the code waits meanwhile doing nothing, just waiting for
> incoming requests
> to arrive (without any requests in it's own internal queues).
> So I suspect the problem is not there. When I run with debugging
> printout I get these kind of messages, which suggest a timeout has
> been exceeded (from what I've read here). But I dont understand how
> could this happen, since I am not servicing any requests meanwhile!

I guess that you are not servicing requests but if you get abort_tasks
you must have "swallowed" one of them previously.

> tgtd: abort_task_set(1008) found 0 0
> tgtd: abort_cmd(984) found 33 6

One task was found pending (after quite a long tmeout).

> Thread 2 (Thread 0x7ffff7635710 (LWP 66234)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
> #1  0x00000000004217b5 in bs_thread_ack_fn (arg=<value optimized out>)
> at bs.c:89

Here we see that one of the backend  threads is waiting for completion.
This may be a completion of an ongoing request, but if you are sure that
you are servicing none, then this may be a symptom of the problem.

It's the following code where cond-variable is being waited upon:
retest:
        if (list_empty(&finished_list)) {
                pthread_cond_wait(&finished_cond, &finished_lock);
                goto retest;
        }

Hope this helps a bit.
Alexander.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html