[asterisk-bugs] [DAHDI-linux 0017289]: VPMADT032 is crashing after upgarde to 2.3.0

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17289 
====================================================================== 
Reported By:                isaacgal
Assigned To:                sruffell
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   17289
Category:                   wcte12xp
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
JIRA:                        
Reviewboard Link:            
====================================================================== 
Date Submitted:             2010-05-05 03:09 CDT
Last Modified:              2010-07-25 19:30 CDT
====================================================================== 
Summary:                    VPMADT032 is crashing after upgarde to 2.3.0
Description: 
just finished upgrading from 2.1.04 to 2.3.0 and calls strated to drop from
time to time. 

I noticed the following in the console log:

wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: Error pinging DSP (2)
wcte12xp 0000:02:08.0: Failed to configure the ports.  Retrying.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.
wcte12xp 0000:02:08.0: VPM present and operational (Firmware version 120)
wcte12xp 0000:02:08.0: VPMADT032 is reenabled.
wcte12xp 0000:02:08.0: VPMADT032 is non-responsive.  Resetting.

i guess there is a bug in the 2.3.0 and VPMADT032 that causes it because
going back to 2.2.0.2 and this issue doesnt happen anymore eventhough new
issues arrived with faxing and echo cancellation, but atleast calls are not
dropping anymore.

the VPMADT032 firmware is 120
asterisk 1.4.30 


====================================================================== 

---------------------------------------------------------------------- 
 (0124997) svnbot (reporter) - 2010-07-25 19:30
 https://issues.asterisk.org/view.php?id=17289#c124997 
---------------------------------------------------------------------- 
Repository: dahdi
Revision: 8982

U   linux/trunk/drivers/dahdi/voicebus/voicebus.c
U   linux/trunk/drivers/dahdi/voicebus/voicebus.h

------------------------------------------------------------------------
r8982 | sruffell | 2010-07-25 19:30:42 -0500 (Sun, 25 Jul 2010) | 14 lines

wcte12xp, wctdm24xxp: Return buffer processing to interrupt handler.

In revision 8095, I had moved most of the buffer processing out of the
interrupt handler and into a tasklet. The intended result was to enable
multiple cards to interleave with one another.  But once again I was
bitten by the fact that there are some systems that for one reason or
another do not process their tasklets in a timely enough manner for the
real-time nature of TDM processing.  This commit moves this processing
back into the interrupt handler by default.  It also limits the number
of frames that the interrupt handler will process at any given time
which appears to achieve the same intended result.

(closes issue https://issues.asterisk.org/view.php?id=17289)
Tested by: alecdavis
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=8982 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-25 19:30 svnbot         Note Added: 0124997                          
======================================================================