Re: mISDN_send: error -12 strikes again

Hi,

On Fri, Mar 16, 2012 at 12:54:52PM +0100, Ralf Schlatterbeck wrote:
> System: Debian Stable, kernel 2.6.32-5-amd64
> lcr: 129a76d1411166176db646138b35e8f5ed9907a2 from Feb 20 2011
> mISDNuser and mISDN around the same time. mISDN is slightly older (some
> commits broke compilation on older kernels).
> 
> I've verified that the current chan_misdn didn't change anything
> concerning locking compared to the old version above.
> 
> Yesterday we had the message "mISDN_send: error -12" filling
> /var/log/kern.log. Restarting asterisk "fixed" it.
> 

I saw this too while working on the mISDN CAPI, if I did make the
CPU's busy so here was high load on the system. Then I looked deeper in it
and found the reason why this did happen. The network socket system accounts
every queued skb, but I thought that the default queue limit should be big
enough. Unfortunately the acoounting code use the real SKB size, not the
used buffer size.
The old code did  always allocate a full big skb 
for receiving and did not copy the data to a smaller one, if only small
buffers are used and even the ACK packets were full size SKBs. So the
the queue gets full very quickly if the userspace stuck for only few 100 ms.

I changed this behavior (copy small packets, allocate packets with a
matching size) in the newer versions and did not get this error anymore,
even with high load.
Note that with the CAPI the error always recovered with the old code, but the
FAX aborted and was resent, so I assume here is still a other problem with
LCR or the DSP channel to handle queue full/OOM correctely.


> When this happened "lcradmin state" and "core show channels" in asterisk
> had different ideas on the channels in use: lcradmin showed three busy
> channels while asterisk showed only one.
> 

I think here is some locking issue involved and/or a wrong error path, normally
if a queue full happens, it should recover if the userspace is ready again,
but it seems when the error occurs in a bad moment, the locking is not
released or it wait for a ACK packet, which will never happen (because it
was discarded in the socket layer).


Karsten