Summary:ASTERISK-01799: Kernel crash during connecting / disconnecting form the conferencing
Reporter:xalex (xalex)Labels:
Date Opened:2004-06-11 12:10:50Date Closed:2004-09-25 02:42:33
Versions:Frequency of
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 ....


Dell PowerEdge 1750
Dual Xeon 2.8 GHz (hyperthreading off)
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


I did extencive testing. As for me problem is fixed.

By: Malcolm Davenport (mdavenport) 2004-06-18 11:25:06