Summary:	ASTERISK-01799: Kernel crash during connecting / disconnecting form the conferencing
Reporter:	xalex (xalex)	Labels:
Date Opened:	2004-06-11 12:10:50	Date Closed:	2004-09-25 02:42:33
Priority:	Critical	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) ksymoops-result.txt ( 1) ksymoops-result-noopt.txt
Description:	We are experincing a crash with kernel panic always seems at the same place (see ksymoops-result.txt attached)  It happens during connect / disconnect form the conference when bux is under load i.e. 100 or more sip connections.  We use digium single port FXO as a timer since we need to use SMP and ohci usb is not supported.  I guess reason, I put this bug here is the contents of the oops pointing to zapatel .... ****** ADDITIONAL INFORMATION ****** Dell PowerEdge 1750 Dual Xeon 2.8 GHz (hyperthreading off) 1 GB RAM WCFXO Redhat 9.0 Kernel 2.4.25 with SMP support
Comments:	By: xalex (xalex) 2004-06-11 12:15:12 One more thing.  Add the beginging of the kernel dumps the following message is always displayed: Unable to handel kernel NULL pointer derefernce at virtual address 0000007f printing eip: f8a017b6 By: Mark Spencer (markster) 2004-06-11 18:18:17 Are you running from CVS zaptel? By: xalex (xalex) 2004-06-11 18:33:18 Yes, but I am not sure it is the latest checkout.  Do you know it was fixed earlier? By: Mark Spencer (markster) 2004-06-11 19:02:35 There was a fix 1-2 months ago that solved this problem for a customer who also was doing SMP with lots of SIP calls.  If you can duplicate this problem, please try to update to latest CVS and duplicate it.  Your ksymoops is a good starting point -- I jsut hope it will give me enough information. Another thing that would be valuable is if you could compile without optimizations (or with just -O if it's required) so that gcc doesn't inline the functions and we can figure out if it's really happening in that particular function or not. By: xalex (xalex) 2004-06-12 12:55:57 We had code dated June 3rd so your hypothesis was not proved.  I ran cvs update just in case and compiled.  It crashed again.  Then I compiled code without optimization. It lived about an hour longer than usual and died again.  I uploaded oops of the crash with &ASTERISK-165;not optimized&ASTERISK-165; compile. By: rmarchev (rmarchev) 2004-06-14 17:27:21 I was able to reproduce the problem looks like issue 0000963 came back. By: Mark Spencer (markster) 2004-06-15 22:47:48 Okay I've updated CVS of zaptel to hold the big zap lock during allocation and free of pseudo channels.  Please confirm this fixes the problem. By: Mark Spencer (markster) 2004-06-16 23:31:16 Please update as of tomorrow morning and make sure the problem is fixed, please. By: rmarchev (rmarchev) 2004-06-18 11:20:36 Mark, I did extencive testing. As for me problem is fixed. Thanks. By: Malcolm Davenport (mdavenport) 2004-06-18 11:25:06 Resolving.