[asterisk-bugs] [DAHDI-linux 0017620]: High CPU utlization by ksoftirqd since enabling of internal timing in r8053
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Jul 12 13:45:03 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17620
======================================================================
Reported By: seanbright
Assigned To: sruffell
======================================================================
Project: DAHDI-linux
Issue ID: 17620
Category: dahdi (the module)
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
JIRA:
Reviewboard Link:
======================================================================
Date Submitted: 2010-07-10 13:22 CDT
Last Modified: 2010-07-12 13:45 CDT
======================================================================
Summary: High CPU utlization by ksoftirqd since enabling of
internal timing in r8053
Description:
Running on a Dell PowerEdge R610 with 2 TCE400B transcoder cards. Also
reproducible on a Dell PowerEdge T310 with no DAHDI hardware at all.
'top' shows ksoftirqd taking up 30-60% of CPU once dahdi is loaded and
load average rises, even without asterisk loaded. Before r8053, this
problem does not manifest.
I have marked this bug as affecting 2.3.0, but I have tested with
dahdi-linux/trunk and it is still occurring.
Please let me know what other information I can provide.
======================================================================
----------------------------------------------------------------------
(0124520) svnbot (reporter) - 2010-07-12 13:45
https://issues.asterisk.org/view.php?id=17620#c124520
----------------------------------------------------------------------
Repository: dahdi
Revision: 8868
U linux/trunk/drivers/dahdi/dahdi-base.c
U linux/trunk/drivers/dahdi/dahdi_dummy.c
------------------------------------------------------------------------
r8868 | sruffell | 2010-07-12 13:45:02 -0500 (Mon, 12 Jul 2010) | 12 lines
dahdi: Explicitly ensure we don't schedule a timer for the current tick.
As best as I can tell, when CONFIG_NO_HZ is set along with CONFIG_HZ <
250, it
is possible for the system timer to exceed MAX_SOFTIRQ_RESTART. Tony
Mountifield alluded that this might be a problem in the below mailing list
posting, but when I was originally testing, I wasn't using CONFIG_NO_HZ
and HZ
< 250.
http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg37384.html
(closes issue https://issues.asterisk.org/view.php?id=17620)
Reported by: seanbright
------------------------------------------------------------------------
http://svn.digium.com/view/dahdi?view=rev&revision=8868
Issue History
Date Modified Username Field Change
======================================================================
2010-07-12 13:45 svnbot Checkin
2010-07-12 13:45 svnbot Note Added: 0124520
======================================================================
More information about the asterisk-bugs
mailing list