I dont use the bs layer at all, so the problem is not there.
I've added a dump_cdb call on target.c:abort_task_set. Sometimes I see
printouts as if WRITE(10) have been lost. Twice I've also seen
SYNCHRONIZE_CACHE(10) aborted. However sometimes nothing gets printed,
suggesting I'm aborting no cmd. Very strange.
I tried tracking all incoming unserviced requests to my code, and
print all these on abort_task_set, but I get nothing, verifying that
indeed my code is servicing all the requests it gets.
Could it be that the request gets lost somewhere up the code stack?
On Thu, Jun 13, 2013 at 6:18 PM, Alexander Nezhinsky
<nezhinsky@xxxxxxxxx> wrote:
> 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
