[asterisk-r2] Alarm on openR2 spans leave channels with RxCAS 0xC state

[Marcelo Pacheco]

Moises,

Sure. I'll test it. Are you confident no changes were made that could 
fix this from 1.3.1 -> 1.3.2 ? I just upgraded, not enough time to 
notice if this is fixed.

Could this be a TDM card driver bug ? How does the DAHDI driver passes 
CAS bit changes to userland (change notifications, or userland 
constantly polls the bits and compare with the prior value) ? Perhaps 
could the driver be failing to pass changes in the bits to userland 
right after the alarm clears, keeping some corrupted state read during 
the alarm. Its interesting that 80+% of times this happens, only 3-6 
channels get blocked with 0xC.

Marcelo

On 01/10/12 20:42, Moises Silva wrote:
> On Tue, Jan 10, 2012 at 5:30 PM, Marcelo Pacheco <marcelo at m2j.com.br 
> <mailto:marcelo at m2j.com.br>> wrote:
>
>     I have the following chan_dahdi.conf (asterisk 1.6.2.18 / dahdi
>     2.3.0.1 / openR2 1.3.1):
>
>     [channels]
>     usecallerid=yes
>     echocancel=no
>     echocancelwhenbridged=no
>
>     signalling=mfcr2
>     mfcr2_variant=br
>     mfcr2_forced_release=no
>     mfcr2_get_ani_first=no
>     mfcr2_category=national_subscriber
>     mfcr2_allow_collect_calls=yes
>     mfcr2_double_answer=no
>
>     context=entrada
>     group=1
>     mfcr2_max_ani=14
>     mfcr2_max_dnis=4
>     channel => 1-15,17-21
>
>     context=geral
>     group=2
>     mfcr2_max_ani=4
>     mfcr2_max_dnis=16
>     channel => 32-46,48-52
>
>     And the following /etc/dahdi/system.conf
>
>     span=1,1,0,cas,hdb3
>     span=2,0,0,cas,hdb3
>     span=3,0,0,esf,b8zs
>     span=4,0,0,ccs,hdb3
>     cas=1-15,17-21:1101
>     cas=32-46,48-52:1101
>     fxoks=63-86
>     bchan=87-101,103-117
>     dchan=102
>     echocanceller=mg2,1-15,17-21,32-46,48-52,63-86
>     loadzone = us
>     defaultzone=us
>
>
>     /etc/asterisk/chan_dahdi.conf (removed the comments to save space)
>
>     [channels]
>     usecallerid=yes
>     callwaiting=no
>     usecallingpres=yes
>     callwaitingcallerid=yes
>     threewaycalling=yes
>     transfer=yes
>     canpark=yes
>     cancallforward=yes
>     callreturn=yes
>     echocancel=yes
>     echocancelwhenbridged=no
>
>     group=1
>     callgroup=1
>     pickupgroup=1
>
>     signalling=mfcr2
>     mfcr2_variant=br
>     mfcr2_forced_release=no
>     mfcr2_get_ani_first=no
>     mfcr2_category=national_subscriber
>     mfcr2_max_ani=14
>     mfcr2_max_dnis=4
>     mfcr2_allow_collect_calls=yes
>     context=entrada
>     group=1
>     channel => 1-15,17-21
>
>     mfcr2_max_ani=8
>     mfcr2_max_dnis=16
>     context=geral
>     group=2
>     channel => 32-46,48-52
>
>
>     switchtype=euroisdn
>     signalling=pri_net
>     group=4
>     context=geral
>     channel => 87-101,103-117
>
>
>     Frequently, after we get an alarm and the alarm clears, some or
>     all channels are left with Rx CAS 0xC state.
>     Reloading dahdi solves the issue, but it's extremely undesirable
>     since this condition might leave no channels or very few channels
>     in operable state for usage until restarting dahdi (and restarting
>     dahdi kills all active dahdi calls). I just upgraded to OpenR2
>     1.3.2, but I saw nothing on the ChangeLog that might fix this.
>
>
> If you can reproduce this reliably and are willing to test a patch, I 
> can write one.
>
> Can you reproduce the issue easily by unplugging/plugging the cable 
> multiple times to generate alarms?
>
> *Moises Silva
> **/Software Engineer, Development Manager/***
>
> msilva at sangoma.com <mailto:msilva at sangoma.com>
>
> Sangoma Technologies
>
> 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
>
> 	
>
>
> t.   +1 800 388 2475 (N. America)
>
> t.   +1 905 474 1990 x128
>
> f.   +1 905 474 9223
>
> 	
>
> ** 
> <http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures>
>
> Products 
> <http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Solutions 
> <http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Events 
> <http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Contact 
> <http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Wiki 
> <http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Facebook 
> <http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures> | 
> Twitter 
> <http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`| 
> | YouTube 
> <http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-r2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20120110/a02ba0d4/attachment-0001.htm>