the error is in libcallweaver.so Because when i simply replace the libcallweaver.so with one that was compiled with a pure ./configure its working without the error.

after long long debugging (but i really learned a lot about the internal structure of CW) i found, that the error is because the cw_hangup function in channel.c need to long to (re)close the cdr. And then we get a race condition so that the

if (p->owner && cw_mutex_trylock(&p->owner->lock)) does grap in sipsock_read/chan_sip, retrys 100times and then gives us the error.

Still dont know why the cdr closing does need longer with CW@Flash-HDD, but here starts the reason for the delay.

ok, it’s cdr_sqlite3! Because when cw_hangup function in channel.c tell the cdr’s it is closing time, then cdr_sqlite3 needs to long to write to cdr.db on a Flash-HDD. That’s it. So i just noload it. It should not be a hard job to code a lock/wait until cdr_sqlite3 or other cdr are ready, but this job can be done um, well… later :)

More details: cw_hangup calls all cdr’s to close now with post_cdr in cdr.c And here is also called res_sqlite to close now. Both res_sqlite and cdr_sqlite3 write slow on a Flash-HDD, so the hole cw_hangup progress does need unnaturally long time (up to 40ms)

For me not a problem. I dont need them both, so i just unload them. But perhaps i would be a idea to set a mark that cw_hangup is in progress, then sipsock_read can check if the channel owner is in hangup progress and does not need to lock it anymore, and dont need to throw us error messages.

The sqlite backends are probably doing fsyncs as part of their commit handling (they should be anyway). Not all filesystems, block device drivers and hard disks do proper write flushing and SSDs so far tend to have poor write performance, especially when they get small writes flushed separately. So the time to flush CDRs can vary a lot.

Then there’s the way the legacy * code (ab)uses locks. That isn’t going to change in a hurry and almost certainly not in the stable 1.2 branch.

What you can try is to use “batch = yes” in cdr.conf. That causes CDRs to be queued and written out in a separate background thread. I think the original intention was to batch updates to optimize database updates but a useful side-effect is that channel handling is no longer at the mercy of whatever the CDR backends are doing.

Thanks! It is working with batch = yes.

I have also find a other solution, that was to do the:

cw_cdr_detach(chan->cdr)

Just a lite bit later in cw_hanhup. After:

if (chan->tech->hangup)
       res = chan->tech->hangup(chan);

That was also working for me.