[asterisk-bugs] [Asterisk 0013959]: Zaptel/DAHDi freezes E1 PRI channels when recieving fax.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=13959 
====================================================================== 
Reported By:                vinsik
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13959
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.23 
Regression:                 Yes 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-11-24 07:23 CST
Last Modified:              2009-05-26 10:06 CDT
====================================================================== 
Summary:                    Zaptel/DAHDi freezes E1 PRI channels when recieving
fax.
Description: 
Asterisk locks up when trying to send fax from E1 PRI to SIP ATA device.
(Outbound works)
CLI stops responding when you try to access DAHDi or channel related
info.
Also 2M link is dropped down when this lock occurs.

Only asterisk restart helps.

This is 'core show locks' output:

=== <file> <line num> <function> <lock name> <lock addr> (times locked)
===
=== Thread ID: 3079187344 (pri_dchannel         started at [ 9697]
chan_dahdi.c start_pri())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (chan_dahdi.c): MUTEX
8678 pri_dchannel &pri->lock
0xb7940e24 (1)
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=1
(chan_dahdi.c): MUTEX 9424 pri_dchannel
&pri->pvts[chanpos]->lock 0x821b6f8 (1)
=== --- ---> Locked Here: chan_dahdi.c line 4753 (dahdi_read)
=== -------------------------------------------------------------------
===
=== Thread ID: 3069733776 (autoservice_run      started at [  228]
autoservice.c ast_autoservice_start())
=== ---> Waiting for Lock https://issues.asterisk.org/view.php?id=0 (channel.c):
MUTEX 1682 ast_waitfor_nandfds
&c[x]->lock 0x8281548 (1)
=== --- ---> Locked Here: channel.c line 1978 (__ast_read)
=== -------------------------------------------------------------------
===
=== Thread ID: 3069979536 (ss_thread            started at [ 9060]
chan_dahdi.c pri_dchannel())
=== ---> Lock https://issues.asterisk.org/view.php?id=0 (channel.c): MUTEX 1978
__ast_read &chan->lock 0x8281548
(1)
=== ---> Lock https://issues.asterisk.org/view.php?id=1 (chan_dahdi.c): MUTEX
4753 dahdi_read &p->lock 0x821b6f8
(1)
=== ---> Lock https://issues.asterisk.org/view.php?id=2 (pbx.c): RDLOCK 6127
ast_rdlock_contexts &conlock
0x81bde40 (1)
=== -------------------------------------------------------------------

Have tried asterisk-1.4.23-rc1 and DAHDi (linux/tools) 2.1.0-rc4.

I can provide more information if needed.
====================================================================== 

---------------------------------------------------------------------- 
 (0105424) arnd (reporter) - 2009-05-26 10:06
 https://issues.asterisk.org/view.php?id=13959#c105424 
---------------------------------------------------------------------- 
Yes, under vanilla 1.4.18, I don't encounter this Problem. 

Under 1.4.19 it happens instantly.
To reproduce:
I made a Faxcall (in my examples always inbound Zap=>iaxmodem/hylafax).
During the call I enter "core show channels" in a cli session.
The cli shows then the IAX Channel, but hangs before it shows the Zap
Channel.

BTW: 
I haven't really used the feature faxdetect in zapata.conf. But from my
development days, this option was set, as I played with it.
I don't have a fax extension. Maybe that's somehow related. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-26 10:06 arnd           Note Added: 0105424                          
======================================================================