On Thu, Jun 13, 2013 at 11:55 AM, osishkin osishkin <osishkin@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
