[asterisk-bugs] [DAHDI-linux 0014183]: sending a large number of calls to app_meetme causes kernel panic
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Jan 20 09:44:51 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14183
======================================================================
Reported By: TerryWhelan
Assigned To: sruffell
======================================================================
Project: DAHDI-linux
Issue ID: 14183
Category: wct4xxp
Reproducibility: always
Severity: crash
Priority: normal
Status: acknowledged
======================================================================
Date Submitted: 2009-01-06 13:19 CST
Last Modified: 2009-01-20 09:44 CST
======================================================================
Summary: sending a large number of calls to app_meetme causes
kernel panic
Description:
On machine 1 create a dial file that calls machine 2 plays about 30 seconds
of test messages and hangup. Create one of these every 5 seconds. On
machine 2 put all incoming calls into a meetme conference. After a couple
of hundred calls machine 2 kernel panics. I have dialed in using SIP and
on the PRI.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014270 kernel panic on VMWare
======================================================================
----------------------------------------------------------------------
(0098193) sruffell (administrator) - 2009-01-20 09:44
http://bugs.digium.com/view.php?id=14183#c98193
----------------------------------------------------------------------
An update for people who are following this. I was able to reproduce this
as TerryWhelan said by using sipp to pump a bunch of calls into Meetme.
However I don't yet have a fix. I can't just revert the change where the
problem was introduced because that was a fix to another issue caused by
the new pluggable echo canceler architecture. Essentially, hw_echocan_off
can't be called in atomic context, so that means that functions that were
previously called with interrupts disabled can no longer be. I'm still
tracking down exactly what the source of the oops is to make sure that
everything that needs to be protected by the various locks in play here
are.
You know, in thinking about it, I guess I could always punt and make sure
that the echocanwith_params functions assume they are called in atomic
context... although not ideal...
Issue History
Date Modified Username Field Change
======================================================================
2009-01-20 09:44 sruffell Note Added: 0098193
======================================================================
More information about the asterisk-bugs
mailing list