DAHDI Channels go offhook after a while

I have been running an Asterisk server for a long time and the computer is dying so I have upgraded to a new server. This is a dual Xeon with plenty of ram and disk resources.

The old server has a TDM400P PCI card and the new one is equipped with a TDM410P PCI Express card. Both configurations have one FXO and 3 FXS modules. The old asterisk server was version 1.8 and DAHDI version 2.4.

The new server runs CentOS 7 64bit, Asterisk 13 and DAHDI 2.11.1. All of these were build from the latest sources from the git repositories.

Everything is working fine when the services are stated and it will continue to work for 10-30 min. After that all 3 FXS channels will be dead, showing Hookstatus: Offhook and there is no dial tone. The only way to fix the problem is to restart both asterisk and dahdi.

I have not been able to find any entries in any of the log files that anything happened.

Any ideas of what to look for? Is it a hardware issue with my server, the TDM card or is there anything I have to configure differently?

Thanks
Frank

Well we can’t see anything about configs so we can’t tell you if it is wrong. have you connected the power to the TDM card?-not sure if that is still needed for new cards-

There is no external power on the new card. There was on the old.

Most of the configuration files are the once that comes with “make samples” I only made changes to extensions.conf, sip.conf, voicemail.comf and chan_dahdi.conf. And then use the generated files from dahdi_genconfig

/etc/dagdi/modules

Autogenerated by /sbin/dahdi_genconf (Dahdi::Config::Gen::Modules) on Thu Mar 10 22:08:14 2016

If you edit this file and execute /sbin/dahdi_genconf again,

your manual changes will be LOST.

wctdm24xxp
~

/etc/dahdi/system.conf

Autogenerated by /sbin/dahdi_genconf on Thu Mar 10 23:39:31 2016

If you edit this file and execute /sbin/dahdi_genconf again,

your manual changes will be LOST.

Dahdi Configuration File

This file is parsed by the Dahdi Configurator, dahdi_cfg

Span 1: WCTDM/0 “Wildcard TDM410P” (MASTER)

fxsks=1
echocanceller=mg2,1
fxoks=2
echocanceller=mg2,2
fxoks=3
echocanceller=mg2,3
fxoks=4
echocanceller=mg2,4

Global data

loadzone = us
defaultzone = us

/etc/dahdi/assigned-spans.conf

Autogenerated by /sbin/dahdi_span_assignments on Thu Mar 10 22:13:13 PST 2016

Map devices + local spans to span + base channel number

Device: [] @PCI_Bus_04_Slot_01 /sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.0/0000:04:00.0/pci:0000:04:00.0

/sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.0/0000:04:00.0/pci:0000:04:00.0 1:1:1

/etc/asterisk/sip.conf
register => … // This is working fine, even whan dahdi is offhook.

[vitel-inbound]
type=friend
dtmfmode=auto
host=inbound22.vitelity.net
context=inbound-vitel
defaultuser=***
secret=***
allow=all
insecure=port,invite
canreinvite=no

[vitel-outbound]
type=friend
callerid=***
dtmfmode=auto
host=outbound.vitelity.net
defaultuser=***
fromuser=***
trustrpid=yes
sendrpid=yes
secret=***
allow=all

/etc/asterisk/modules
[modules]
autoload=yes
;
; Any modules that need to be loaded before the Asterisk core has been
; initialized (just after the logger has been initialized) can be loaded
; using ‘preload’. This will frequently be needed if you wish to map all
; module configuration files into Realtime storage, since the Realtime
; driver will need to be loaded before the modules using those configuration
; files are initialized.
;
; An example of loading ODBC support would be:
;preload => res_odbc.so
;preload => res_config_odbc.so
;
; Uncomment the following if you wish to use the Speech Recognition API
;preload => res_speech.so
;
; If you want Asterisk to fail if a module does not load, then use
; the “require” keyword. Asterisk will exit with a status code of 2
; if a required module does not load.
;
; require = chan_sip.so
; If you want you can combine with preload
; preload-require = res_odbc.so
;
; If you want, load the GTK console right away.
;
noload => pbx_gtkconsole.so
;load => pbx_gtkconsole.so
;
load => res_musiconhold.so
;
; Load one of: chan_oss, alsa, or console (portaudio).
; By default, load chan_oss only (automatically).
;
noload => chan_alsa.so
;noload => chan_oss.so
noload => chan_console.so
;
noload => res_phoneprov.so
noload => res_ari_events.so
noload => cdr_pgsql.so
noload => cel_pgsql.so
noload => res_config_pgsql.so
noload => res_config_ldap.so

noload => cdr_adaptive_odbc.so
noload => cdr_odbc.so
noload => cel_odbc.so
noload => func_odbc.so
noload => res_config_odbc.so
noload => res_odbc.so

What other configuration or log files would you be looking for?

After a bit more research I made an interesting observation.

I have a RAID 5 disk in the same box and I use Samba to share the drive with a number of Windows machines. If I don’t mount the RAID drive or I don’t start the Samba service (smbd) there is no problem with the DAHDI channels.

Anyone have any experience using Samba on the same hardware used by the Asterisk system?

Thanks
Frank

Sounds like a hardware conflict with the RAID controller, or excessive interrupt latency in its interrupt service routines. SAMBA works at a too high level to generate this sort of interaction directly.

1 Like

Disabled the RAID controller, switch to plain IDE/SATA and mounted the RAID with software. Everything has been working for a day now.