[Home]

Summary:DAHLIN-00126: [patch] Console full of PRI got event: HDLC Abort (6) on Primary D-channel of span 1
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-07-14 04:28:25Date Closed:2010-04-13 14:54:59
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:wcte12xp
Versions:2.2.0-rc2 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) hdlc_Abort.txt
( 1) mantis-15498-1.patch
( 2) pri-intense-DAHDI-Version-SVN-trunk-r6005.txt
Description:Since Feb we've been running the following version with no problem.
DAHDI Version: SVN-trunk-r6005 Echo Canceller:

After upgrade to DAHDI Version: 2.2.0 Echo Canceller:
we get the following constantly on the console and hardly ever able to establish a call

 == Primary D-Channel on span 1 down
[Jul 14 21:20:31] WARNING[1464]: chan_dahdi.c:3546 pri_find_dchan: No D-channels available!  Using Primary channel 16 as D-channel anyway!
 == Primary D-Channel on span 1 up
[Jul 14 21:20:31] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
[Jul 14 21:20:32] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
[Jul 14 21:20:33] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
[Jul 14 21:20:34] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
[Jul 14 21:20:35] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
 == Primary D-Channel on span 1 down
[Jul 14 21:20:36] WARNING[1464]: chan_dahdi.c:3546 pri_find_dchan: No D-channels available!  Using Primary channel 16 as D-channel anyway!
 == Primary D-Channel on span 1 up
[Jul 14 21:20:36] NOTICE[1464]: chan_dahdi.c:11381 pri_dchannel: PRI got event: HDLC Abort (6) on Primary D-channel of span 1

****** ADDITIONAL INFORMATION ******

Tried DAHDI Version: 2.2.0-rc2 Echo Canceller:
Same messages.

Tried DAHDI Version: 2.2.0-rc1 Echo Canceller:
Which is earlier than SVN-trunk-r6005 and no problem.

/etc/dahdi/system.conf
span=1,0,0,ccs,hdb3,crc4
bchan=1-15,17-31 # set this to 1-15,17-31 for E1
dchan=16 # set this to 16 for E1

/etc/asterisk/chan_dahdi.conf
group = 0
pridialplan = unknown
prilocaldialplan = unknown
facilityenable=yes
transfer=yes
switchtype=qsig
signalling=pri_cpe
qsigchannelmapping=physical
echocancel=yes
echotraining=900
echocancelwhenbridged=no
rxgain=0.0
txgain=0.0
channel => 1-15,17-31






Comments:By: Alec Davis (alecdavis) 2009-07-14 04:57:54

uploaded hdlc_Abort.txt

DAHDI Version: 2.2.0-rc2 Echo Canceller:
which is a PRI call into asterisk voice mail with 'pri intense debug span 1'


By: Alec Davis (alecdavis) 2009-07-14 05:11:26

uploaded pri-intense-DAHDI-Version-SVN-trunk-r6005.txt

which is the same call sequence as previous note but into dahdi version r6005.
By: Michael L. Young (elguero) 2009-07-14 11:26:28

Not sure if this helps but shouldn't your span be getting its timing from the network since I see you have signalling set as pri_cpe?

span=1,1,0,ccs,hdb3,crc4 instead of span=1,0,0,ccs,hdb3,crc4

Just a quick thought.

Also in pri-intense debug file I saw this:
[Jul 14 22:00:17] WARNING[3828]: app_voicemail.c:8741 vm_authenticate: Couldn't read username
By: Alec Davis (alecdavis) 2009-07-14 14:31:33

elguero: You maybe onto it. But even if it does fix it, I wonder why it's worked for so long, as no configurations changed just DAHDI.
By: Alec Davis (alecdavis) 2009-07-14 14:45:46

Just tried span=1,1,0,ccs,hdb3,crc4 and same results.

fails: (only tested) with DAHDI Version: 2.2.0-rc2
works: DAHDI-Version-SVN-trunk-r6005

elguero: the vm_authenticate error was becasue I hungup early.
By: Alec Davis (alecdavis) 2009-07-15 05:02:12

r6527 is the beginning of the HDLC ABORT errors.

In an attempt to find out at which patch release it breaks did the following;

svn checkout http</u>://svn.digium.com/svn/dahdi/linux/trunk@6526 dahdi-linux-6526
and
svn checkout http</u>://svn.digium.com/svn/dahdi/linux/trunk@6527 dahdi-linux-6527

and obviously a 'make' and 'make install' from appropriate dirs.

6526 doesn't have HDLC_ABORTS
  but does have
  [Jul 15 21:41:52] WARNING[13892]: chan_dahdi.c:2111 dahdi_enable_ec: Unable to enable echo c

6527 does have the HDLC_ABORTS
6527 has significant changes regarding voicebus
  voicebus: Move common vpmadt032 interface into voicebus module.


By: Shaun Ruffell (sruffell) 2009-07-15 14:13:53

alecdavis:  I've attached mantis-15489-1.patch which I believe will fix this.  Could you give it a try in your environment?
By: Alec Davis (alecdavis) 2009-07-15 16:36:00

sruffell:
This to hopefully fix the HDLC ABORTS?

Or does it fix the problem mentioned in the last note of "unable to enable echo canceller"?

Will test after hours tonight, 10 hours away at least (NZST).

Alec
By: Shaun Ruffell (sruffell) 2009-07-15 16:42:17

alecdavis: The HDLC aborts.  You should be able to apply that patch to 2.2.0.1 and be up and running, but I'm testing it some more myself before merging.


By: Alec Davis (alecdavis) 2009-07-15 17:43:03

Are any other cards affected in the same way?
We use the TE220/wct4xxp in 2 of our other sites?
By: Shaun Ruffell (sruffell) 2009-07-15 17:47:48

No...this particular issue would only affect the wcte12xp based cards.
By: Alec Davis (alecdavis) 2009-07-16 00:06:40

Managed to get mantis-15489-1.patch tested before end of day.

Applied mantis-15489-1.patch to dahdi-linux-6527
result No HDLC Aborts, but far end could hardly hear me, static etc.

Then applied to dahdi-2.2.0 tag release.
result No HDLC Aborts, and good audio both ways.

Alec
By: Digium Subversion (svnbot) 2009-07-16 12:29:54

Repository: dahdi
Revision: 6844

U   linux/trunk/drivers/dahdi/wcte12xp/base.c

------------------------------------------------------------------------
r6844 | sruffell | 2009-07-16 12:29:54 -0500 (Thu, 16 Jul 2009) | 10 lines

wcte12xp: Disable vpmadt032 companding by default.

This fixes a regression in 2.2.0 where certain configurations will fail
patloop test or have repeated HDLC aborts because the VPMADT032 is modifying
the clear channel or d channel data streams.  This restores the behavior to
how it was in dahdi-linux 2.1.0.4.

(closes issue DAHLIN-126)
Reported by: alecdavis
Tested by: alecdavis
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=6844
By: Digium Subversion (svnbot) 2009-07-21 13:11:57

Repository: dahdi
Revision: 6864

_U  linux/branches/2.2/
U   linux/branches/2.2/drivers/dahdi/dahdi-base.c
U   linux/branches/2.2/drivers/dahdi/tor2.c
U   linux/branches/2.2/drivers/dahdi/wct4xxp/base.c
U   linux/branches/2.2/drivers/dahdi/wcte11xp.c
U   linux/branches/2.2/drivers/dahdi/wcte12xp/base.c
U   linux/branches/2.2/include/dahdi/dahdi_config.h

------------------------------------------------------------------------
r6864 | sruffell | 2009-07-21 13:11:56 -0500 (Tue, 21 Jul 2009) | 53 lines

Merged revisions 6844,6852,6862-6863 via svnmerge from
https://origsvn.digium.com/svn/dahdi/linux/trunk

........
 r6844 | sruffell | 2009-07-16 12:29:53 -0500 (Thu, 16 Jul 2009) | 10 lines
 
 wcte12xp: Disable vpmadt032 companding by default.
 
 This fixes a regression in 2.2.0 where certain configurations will fail
 patloop test or have repeated HDLC aborts because the VPMADT032 is modifying
 the clear channel or d channel data streams.  This restores the behavior to
 how it was in dahdi-linux 2.1.0.4.
 
 (closes issue DAHLIN-126)
 Reported by: alecdavis
 Tested by: alecdavis
........
 r6852 | tzafrir | 2009-07-19 10:45:40 -0500 (Sun, 19 Jul 2009) | 12 lines
 
 tor2: allow using port4 as timing source
 
 Fix a silly regression introduced when strict check on the timing
 parameter was added (sync-1 is the array index, not sync itself. And 0
 is a special case).
 
 (closes issue DAHLIN-120)
 Reported by: dferrer
 Patches:
       tor2-4th_sync.patch uploaded by dferrer (license 525)
........
 r6862 | sruffell | 2009-07-21 12:52:59 -0500 (Tue, 21 Jul 2009) | 4 lines
 
 Revert "wct4xxp, wcte11xp: Use the default configuration by default at startup."
 
 This reverts the change introduced by revision 6712.  This change can cause
 problems when there is a VPM module installed on the quad-span digital cards.
........
 r6863 | sruffell | 2009-07-21 12:53:02 -0500 (Tue, 21 Jul 2009) | 12 lines
 
 dahdi-base: Add support for core timing.
 
 This essentially moves the function of dahdi_dummy into the core of DAHDI.  It
 ensures that if DAHDI is loaded, it will always be able to provide timing,
 regardless of whether there are board drivers loaded, or if the board drivers
 are properly calling dahdi_receive.
 
 If there is a master span loaded which is calling dahdi_receive, then the
 behavior will be like it is normally.
 
 This functionality is off by default, uncomment CONFIG_DAHDI_CORE_TIMER in
 include/dahdi/config_dahdi.h in order to enable it.
........

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=6864
By: viniciusfontes (viniciusfontes) 2009-11-10 10:31:36.000-0600

Problem still happens when using DAHDI-Linux 2.2.0.2 and DAHDI-Tools 2.2.0. The problem only happens when all these criteria are met:

- E1 (ccs,hdb3)
- ISDN protocol (I'm using signalling=euroisdn)
- VPMADT032 is physically present

When the VPMADT032 is physically removed the problem no longer happens. Actually I had to remove it in order to get a stable link with the telco. Also tried:

echo 0 > /sys/module/wcte12xp/parameters/vpmsupport

But the problem still happens.
By: Shaun Ruffell (sruffell) 2009-11-10 10:35:30.000-0600

vinicusfontes: What happens when you add "options wcte12xp vpmsupport=0" to /etc/modprobe.d/dahdi and the VPMADT032 is physically present?

(Unfortunately, the file permissions on the module parameters are wrong....echoing to the vpmsupport parameter after the fact will not disable the VPM.  It should be read only).
By: Shaun Ruffell (sruffell) 2009-11-10 10:35:48.000-0600

Also, could you try with revision 7550 of the 2.2 branch?
By: viniciusfontes (viniciusfontes) 2009-11-10 10:37:04.000-0600

Good to know!
I'll be able to test this in about four hours and I'll post the results here.
By: Shaun Ruffell (sruffell) 2009-11-13 11:36:51.000-0600

viniciusfontes: any results?
By: viniciusfontes (viniciusfontes) 2009-11-13 11:42:24.000-0600

I set up two boxes on my lab in order to reproduce the problem before getting the svn version. So far, over 100000 calls and no problem at all. Both systems are running DAHDI 2.2.0.2 and one of them has a VPMADT032.

Maybe something went wrong when I updated that problematic system to 2.2.0.2 and the wcte12xp.ko didn't get replaced with the new version. dahdi_cfg -tv still reported DAHDI-Linux as 2.2.0.2 and DAHDI-tools as 2.2.0 thought. I recompiled DAHDI and Asterisk, used diff to compare the module at /usr/src and the one at /lib/modules, this time they are identical. Asked the customer to install the VPMADT032 again, and will report as soon as he do it.

Looks like it was a false alarm (and for that I apologize in advance) but hey, better like this, isn't it? :)


By: Shaun Ruffell (sruffell) 2009-11-13 11:51:44.000-0600

viniciusfontes: thanks for the update (and sorry about that last post twice, I don't know what happened there).  Although, if you're running DAHDI 2.2.0.2, it may be possible to run into the sort of problems recently resolved as part of DAHLIN-135.

Would you be able to update to the head of the 2.2 branch?  We're going to make a 2.2.1-rc1 tag soon after we're able to run through a set of regression tests in our lab here.
By: viniciusfontes (viniciusfontes) 2009-11-13 12:05:22.000-0600

I guess you're referring to DAHDI not detecting the 2100hz tone to disable all EC right? Unfortunely the E1 board running on my PBX is a TE110P, with no support for VPMADT032. I'm not sure if that issue happens even without a VPMADT032 attached, but if it does I would be glad to test it.
By: Leif Madsen (lmadsen) 2010-04-13 13:50:11

I just noticed 2.3.0 will be going out soon, but this is a marked as a blocker for the next set of releases. Is this really a blocker or should the severity be knocked down?
By: Shaun Ruffell (sruffell) 2010-04-13 14:54:58

I think this was resolved in 2.2.1.  Reopen if I'm mistaken. Thanks.