Summary:	ASTERISK-14486: [patch] chan_dahdi deadlock heavy incomming traffic
Reporter:	adomjan (adomjan)	Labels:
Date Opened:	2009-07-17 13:37:09	Date Closed:	2011-06-07 14:00:55
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_dahdi.c_ast_state_up_locked_pvt.diff
Description:	I had deadlocks ~ 2-3 hours on high incomming ss7 calls. The deadlock happend after the answer. After I moved ast_setstate(ast, AST_STATE_UP); in area where the pvt is locked in dahdi_answer() (like in chan_sip), and protected from the double answer, I have not more deadlocks.
Comments:	By: Leif Madsen (lmadsen) 2009-08-17 13:24:18 I've assigned a couple of chan_dadhi issues to rmudgett, but that may not be the "correct" thing to do. Please let me know if there is someone more appropriate to assign these issues to. Thanks! By: Russell Bryant (russell) 2009-08-17 17:44:22 It's not clear what this patch fixes. Can you provide more information about what deadlock you saw?  What threads and what locks were involved?  In what order were the locks being used in the different threads that caused the deadlock? Ideally, we would like to see output from the "core show locks" CLI command after the deadlock has occurred.  To enable this command, Asterisk needs to be compiled with DEBUG_THREADS. By: adomjan (adomjan) 2009-08-20 05:13:42 Forget this, sorry. The problem was outside of dahdi... It is seems stable. My system passed 160k calls within 1 week without any failure By: Dmitry Andrianov (dimas) 2009-08-20 05:33:47 Where the problem was? By: Leif Madsen (lmadsen) 2009-09-22 08:18:04 Closed per the reporter.