Debian Squeeze und DAHDI mit HCF

mase · 13 Feb 2011

Hallo!
Läuft unter Debian Squeeze DAHDI mit HCF Karten nicht mehr richtig?
Im Log steht:

Code:

[Feb 13 03:22:21] ERROR[8164] res_timing_dahdi.c: Asterisk has detected a problem with your DAHDI configuration and will shutdown for your protection.  You have options:
	1. You only have to compile DAHDI support into Asterisk if you need it.  One option is to recompile without DAHDI support.
	2. You only have to load DAHDI drivers if you want to take advantage of DAHDI services.  One option is to unload DAHDI modules if you don't need them.
	3. If you need DAHDI services, you must correctly configure DAHDI.
For more information on Asterisk timing modules, including ways to potentially fix this problem, please see doc/timing.txt

Ein dahdi_cfg -vvvv gibt:

Code:

DAHDI Version: 2.3.0.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: Hardware assisted D-channel (Default) (Echo Canceler: none) (Slaves: 03)

3 channels to configure.

Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to none

Anrufe funktionieren zwar trotzdem, aber es stottert ziemlich.

Hier meine system.conf:

Code:

span=1,1,0,ccs,ami
bchan=1-2
hardhdlc=3
echocanceller=oslec,1-2

# Global data

loadzone        = de
defaultzone     = de

und meine chan_dahdi.conf:

Code:

[trunkgroups]

[channels]
language=de
switchtype=euroisdn

pridialplan=unknown
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
;localprefix = VORWAHL
;privateprefix = VORWAHL+MSN
unknownprefix =
priindication = outofband

facilityenable = yes
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
immediate=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default

group=1
signalling=bri_cpe_ptmp
; p2p TE mode  => bri_cpe
; p2mp TE mode => bri_cpe_ptmp
; p2p NT mode  => bri_net
; p2mp NT mode => bri_net_ptmp
context=isdn-in
channel => 1-2

privi · 2 Mrz 2011

Ich mach jetzt auch schon wieder Tagelang mit dem scharrn rum. Drecks HFC Patches, funktioneren alle nicht. Und dann noch DAHDI, mISDN, zap was weiß ich nich, alles pfusch.

Gibt es wirklich eine lauffähige Version mit Debian? Ich nehm von mir aus auch ne ur alte, nur sowas wie Gentoo will ich halt nicht...

Ich glaube ich sollte aufgeben... ich spüre es ganz deutlich...

Im Moment scheitere ich an

Code:

[Mar  2 18:23:35] WARNING[3856]: app_dial.c:1745 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 34 - Circuit/channel congestion)

wie siehts bei euch so aus?

mase · 2 Mrz 2011

Die o. g. Konfiguration funktioniert zwar mit Squeeze, aber halt mit den
Fehlermeldungen. Anrufe funktionieren. Das stottern lag am Nokia N900.
Da musste ich bei Anrufen die dynamische Prozessortaktung deaktivieren.
Wenn's ohne Fehlermeldungen sein soll, dann nimm Debian Lenny. Da
ist noch zaptel dabei.

privi · 2 Mrz 2011

Welche Pakete hast Du da genau mit aptitude installiert? dahdi-dkms gibts zum Beispiel bei mir gar nicht mehr.

mase · 2 Mrz 2011

Ich hab dahdi-linux installiert, und mit m-a das Kernelmoduls aus dahdi-source gebaut.

privi · 2 Mrz 2011

mase schrieb:
Ich hab dahdi-linux installiert, und mit m-a das Kernelmoduls aus dahdi-source gebaut.

Bei mir funktionierts - zumindest nach einem kurzen test - jetzt auch. Eigentlich ganz einfach.

@mase: Ich gebe bescheid, ob ich ähnliche Stabilitätsprobleme bekomme wie Du.

Installationsanleitung für PLAIN-Debian Squeeze 64 Bit zur funktionierenden Asterisk-Lösung mit HFC-S: (Punkt 1 ist nur notwendig wenn man XEN macht.)

1. mv /lib/modules/2.6.32-5-xen-amd64/kernel/drivers/isdn/hardware/mISDN/hfcpci.ko /lib/modules/2.6.32-5-xen-amd64/kernel/drivers/isdn/hardware/mISDN/hfcpci.ko.old
2. mv /lib/modules/2.6.32-5-amd64/kernel/drivers/isdn/hardware/mISDN/hfcpci.ko /lib/modules/2.6.32-5-amd64/kernel/drivers/isdn/hardware/mISDN/hfcpci.ko.old
3. rmmod hfcpci
4. rmmod mISDN_core
5. apt-get install dahdi dahdi-linux dahdi-source asterisk linux-headers-`uname -r`
6. cd /usr/src/
7. tar -xjvf dahdi.tar.bz2
8. cd modules/dahdi
9. make
11. make install # Hier kommen viele Fehler mit irgendwelchen Firmwares, geht aber trotzdem
12. Konfigfiles:

/etc/dahdi/modules

Code:

dahdi
zaphfc
dahdi_transcode
dahdi_echocan_oslec

/etc/dahdi/system.conf

Code:

span=1,1,0,ccs,ami
bchan=1-2
hardhdlc=3
echocanceller=oslec,1-2

# Global data
loadzone        = de
defaultzone     = de

/etc/asterisk/chan_dahdi.conf

Code:

[trunkgroups]

[channels]
language=de
switchtype=euroisdn

pridialplan=unknown
prilocaldialplan=unknown
internationalprefix = 00
nationalprefix = 0
;localprefix = VORWAHL
;privateprefix = VORWAHL+MSN
unknownprefix =
priindication = outofband

facilityenable = yes
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
immediate=no
echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
callgroup=1
pickupgroup=1
mohinterpret=default
mohsuggest=default

group=1
signalling=bri_cpe_ptmp
; p2p TE mode  => bri_cpe
; p2mp TE mode => bri_cpe_ptmp
; p2p NT mode  => bri_net
; p2mp NT mode => bri_net_ptmp
context=isdn-in
channel => 1-2

/etc/asterisk/sip.conf

Code:

[2000]
type=friend
secret=1234
host=dynamic

/etc/asterisk/extensions.conf

Zu Ersetzen:
449XXXXX -> Eigene Rufnummer (bei mir (Allice) ohne Vorwahl)
192.168.X.X -> IP des Servers

Code:

[default]
include => isdn

; Teilnehmer 2000 mit Voicebox:
exten => 2000,1,Dial(SIP/2000)

[isdn]
exten => _449XXXXX,1,Dial(SIP/[email protected]) ; Durchwahl 39 ankommend

exten => _0X.,1,Set(CALLERID(num)=449XXXXX)
exten => _0X.,n,Dial(DAHDI/g1/${EXTEN:1})  ; Rausgehende Anrufe

[isdn-in]

exten => 223,1,Dial(SIP/2000)

... und nun beobachten was sich tut oder nicht tut:

13. pkill asterisk
14. /etc/init.d/dahdi start
15. asterisk -f -c
16. core set debug 1 # Im Asterisk Prompt
17. core set verbose 100 # Im Asterisk Prompt

Und raustelefonieren mit der 2000, "0" Vorwählen nicht vergessen!

Achja, die Konfig is nur testen gedacht. Produktiv absichern, damit nicht jemand aus dem Internet teure Gespräche führt!

Wenns jemanden geholfen hat und/oder einen Verbesserungsvorschlag hat, kann er sich ja mal melden.

mase · 3 Mrz 2011

Hast du trotzdem Fehler im Log, oder das
3 channels to configure?

privi · 3 Mrz 2011

Asterisk hat ne Menge an komischen Warnings und Errors... Welche meinst Du genau?

Code:

root@sip:/usr/src/modules/dahdi# asterisk -f -c
Asterisk 1.6.2.9-2+squeeze1, Copyright (C) 1999 - 2010 Digium, Inc. and others.
Created by Mark Spencer <[email protected]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
[ Booting...
[ Reading Master Configuration ]
[ Initializing Custom Configuration Options ]
[Mar  3 11:27:37] NOTICE[11142]: cdr.c:1471 do_reload: CDR simple logging enabled.
[Mar  3 11:27:37] NOTICE[11142]: loader.c:1064 load_modules: 198 modules will be loaded.
..[Mar  3 11:27:37] NOTICE[11142]: res_smdi.c:1361 load_module: No SMDI interfaces are available to listen on, not starting SMDI listener.
[Mar  3 11:27:37] WARNING[11142]: res_config_ldap.c:1591 parse_config: No directory user found, anonymous binding as default.
[Mar  3 11:27:37] ERROR[11142]: res_config_ldap.c:1616 parse_config: No directory URL or host found.
[Mar  3 11:27:37] NOTICE[11142]: res_config_ldap.c:1510 load_module: Cannot load LDAP RealTime driver.
...[Mar  3 11:27:37] NOTICE[11142]: res_odbc.c:1694 load_module: res_odbc loaded.
..[Mar  3 11:27:37] NOTICE[11142]: config.c:1957 ast_config_engine_register: Registered Config Engine sqlite
.........................[Mar  3 11:27:38] NOTICE[11142]: chan_skinny.c:7066 config_load: Configuring skinny from skinny.conf
..............[Mar  3 11:27:38] WARNING[11142]: chan_dahdi.c:17134 process_dahdi: Ignoring any changes to 'userbase' (on reload) at line 23.
[Mar  3 11:27:38] WARNING[11142]: chan_dahdi.c:17134 process_dahdi: Ignoring any changes to 'vmsecret' (on reload) at line 31.
[Mar  3 11:27:38] WARNING[11142]: chan_dahdi.c:17134 process_dahdi: Ignoring any changes to 'hassip' (on reload) at line 35.
[Mar  3 11:27:38] WARNING[11142]: chan_dahdi.c:17134 process_dahdi: Ignoring any changes to 'hasiax' (on reload) at line 39.
[Mar  3 11:27:38] WARNING[11142]: chan_dahdi.c:17134 process_dahdi: Ignoring any changes to 'hasmanager' (on reload) at line 47.
..[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:122 pbx_load_module: Starting AEL load process.
[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:135 pbx_load_module: AEL load process: parsed config file name '/etc/asterisk/extensions.ael'.
[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:138 pbx_load_module: AEL load process: checked config file name '/etc/asterisk/extensions.ael'.
[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:141 pbx_load_module: AEL load process: compiled config file name '/etc/asterisk/extensions.ael'.
[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:146 pbx_load_module: AEL load process: merged config file name '/etc/asterisk/extensions.ael'.
[Mar  3 11:27:38] NOTICE[11142]: pbx_ael.c:149 pbx_load_module: AEL load process: verified config file name '/etc/asterisk/extensions.ael'.
........[Mar  3 11:27:38] NOTICE[11142]: config.c:1957 ast_config_engine_register: Registered Config Engine curl
..[Mar  3 11:27:38] WARNING[11142]: utils.c:1535 __ast_string_field_init: trying to reset empty pool
[Mar  3 11:27:38] WARNING[11142]: utils.c:1535 __ast_string_field_init: trying to reset empty pool
[Mar  3 11:27:38] WARNING[11142]: utils.c:1535 __ast_string_field_init: trying to reset empty pool
....................................  == Aliased CLI command 'hangup request' to 'channel request hangup'
  == Aliased CLI command 'originate' to 'channel originate'
  == Aliased CLI command 'help' to 'core show help'
  == Aliased CLI command 'pri intense debug span' to 'pri set debug 2 span'
  == Aliased CLI command 'reload' to 'module reload'
................[Mar  3 11:27:38] ERROR[11142]: chan_vpb.cc:2706 ast_module_load_result load_module(): No Voicetronix cards detected
.....[Mar  3 11:27:38] WARNING[11142]: translate.c:654 __ast_register_translator: plc_samples 160 format f
....................................SIP channel loading...
[Mar  3 11:27:38] WARNING[11142]: chan_sip.c:25143 reload_config: Section 'default' lacks type
[Mar  3 11:27:38] WARNING[11142]: chan_sip.c:25143 reload_config: Section 'isdn' lacks type
.......................[Mar  3 11:27:38] WARNING[11142]: res_musiconhold.c:989 moh_scan_files: Cannot open dir /usr/share/asterisk/moh or dir does not exist
[Mar  3 11:27:38] WARNING[11142]: res_musiconhold.c:1795 load_module: No music on hold classes configured, disabling music on hold.
..[Mar  3 11:27:38] ERROR[11142]: ais/clm.c:141 ast_ais_clm_load_module: Could not initialize cluster membership service: Try Again
.................. ]
Asterisk Ready.
*CLI>

Das 3 Channels hab ich auch, ist ja auch okay so, oder?

Code:

root@sip:/usr/src/modules/dahdi# dahdi_cfg -vvvv
DAHDI Tools Version - 2.2.1.1

DAHDI Version: 2.3.0.1
Echo Canceller(s): OSLEC
Configuration
======================

SPAN 1: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)

Channel map:

Channel 01: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 01)
Channel 02: Clear channel (Default) (Echo Canceler: oslec) (Slaves: 02)
Channel 03: Hardware assisted D-channel (Default) (Echo Canceler: none) (Slaves: 03)

3 channels to configure.

Setting echocan for channel 1 to oslec
Setting echocan for channel 2 to oslec
Setting echocan for channel 3 to none
root@sip:/usr/src/modules/dahdi#

mase · 3 Mrz 2011

Ich mein die Meldungen aus meinem ersten Post.

privi · 4 Mrz 2011

Ich habe keine Ahnung wo die Meldungen bei Dir auftauchen. Ich habe diese auf jedenfall noch nicht bemerkt.

Vieleicht mal mit anderer Hardware probieren?

maeusefaenger · 22 Mrz 2011

Debian Squeeze:dahdi und zaphfc laufen nicht: PRI span 1/0: Provisioned, Down, Active

Hallo,

Ich hänge mich hier mal mit dran, denn ich habe ebenfalls Probleme dahdi und zaphfc zum Laufen kriegen. Zwar laufen die Kernel-Module und asterisk soweit mit dem Debian Standardkernel und -paketen, allerdings funktioniert die ISDN-Karte in Asterisk nicht. Man kriegt die bekannte Fehlermeldung "'DAHDI' (cause 34 - Circuit/channel congestion)". Das liegt sicherlich daran, dass der "span" nicht auf "Up" steht:

Code:

*CLI> pri show spans
PRI span 1/0: Provisioned, Down, Active

Außerdem sieht man in Asterisk die ebenfalls bekannte Fehlermeldung:

Code:

ERROR[3661]: chan_dahdi.c:12393 dahdi_pri_error: 1 Unable to receive TEI from network!

Ähnlich wie "privi" habe ich jetzt dahdi und zaphfc eingerichtet, mit dem einzigen Unterschied, dass ich die Module "hfcpci" und "mISDN_core" in der Datei /etc/modprobe.d/blacklist.conf blacklisted habe und die dahdi Kernelmodule mit "m-a a-i dahdi" compiled habe.

Kann mir noch jemand Hinweise geben, wie man das Problem weiter eingrenzen kann?

Ein wenig sonderbar ist, dass die Ausgabe von "dahdi_hardware" bei mir leer ist. Ich vermute, das liegt daran, dass die PCI ID meiner ISDN Karte nicht bekannt ist, aber ich denke das hat auf die Funktionsweise des vzaphfc Kernelmoduls keinen weiteren Einfluss?

Hier die Karte:

Code:

$ lspci -vvvvvv
...
01:07.0 Network controller: Abocom Systems Inc Device 2bd1 (rev 02)
        Subsystem: Abocom Systems Inc Device 2bd1
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+ INTx-
        Latency: 16 (4000ns max)
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at 7800 [disabled] [size=8]
        Region 1: Memory at ee000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
        Kernel driver in use: vzaphfc

(Entgegen der Ausgabe von "lspci" heißt das geladene Kernel-Modul "zaphfc" und nicht "vzaphfc").

Gemäß /proc/interrups teilt sich die Karte den Interrupt mit keiner anderen Karte. Die Verkabelung sollte ebenfalls korrekt sein: die Karte ist direkt am NTBA angeschlossen und unter Debian Lenny funktionierte es bisher.

"dahdi_test" läuft fehlerfrei durch mit Werten um die "99.998%".

Die Debian Quellen vom Paket "dahdi-source" enthalten den Code von der Revision 8 von zaphfc (http://code.google.com/p/zaphfc/source/browse/#svn/branches/2.3/zaphfc). Der einzige Unterschied ist, dass in der base.c vom Debian-Paket in der Funktion "static int hfc_zap_initialize(struct dahdi_hfc *hfccard)" diese Zeile fehlt:

Code:

        hfccard->span.owner = THIS_MODULE;

Ansonsten lässt sich über das zaphfc Modul noch sagen, dass es bei mir ebenfalls den "slowpath" Fehler erzeugt:

Code:

[  141.443783] vzaphfc: HFC-S PCI A ISDN (V1.42) loading
[  141.444371] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[  141.444378]   alloc irq_desc for 17 on node 0
[  141.444381]   alloc kstat_irqs on node 0
[  141.444390] vzaphfc 0000:01:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
[  141.444466] vzaphfc: card 0: registered ZTHFC1/0/1
[  141.444469] vzaphfc: card 0: registered ZTHFC1/0/2
[  141.444471] vzaphfc: card 0: registered ZTHFC1/0/3
[  141.444474] ------------[ cut here ]------------
[  141.444483] WARNING: at /usr/src/modules/dahdi/drivers/dahdi/dahdi-base.c:5866 dahdi_register+0x48/0x321 [dahdi]()
[  141.444486] Hardware name: M61P-S3
[  141.444488] Modules linked in: zaphfc(+) nouveau(+) ttm drm_kms_helper snd_page_alloc dahdi ftdi_sio edac_core edac_mce_amd crc_ccitt k8temp drm i2c_nforce2 usbserial i2c_algo_bit pcspkr i2c_core evdev button processor ext3 jbd mbcache ide_gd_mod ide_core ohci_hcd sd_mod ata_generic crc_t10dif sata_sil24 pata_amd ehci_hcd thermal r8169 sata_promise mii sata_nv forcedeth libata scsi_mod thermal_sys usbcore nls_base [last unloaded: scsi_wait_scan]
[  141.444524] Pid: 925, comm: work_for_cpu Not tainted 2.6.32-5-vserver-amd64 #1
[  141.444527] Call Trace:
[  141.444533]  [<ffffffffa026fed7>] ? dahdi_register+0x48/0x321 [dahdi]
[  141.444538]  [<ffffffffa026fed7>] ? dahdi_register+0x48/0x321 [dahdi]
[  141.444544]  [<ffffffff8104e4d4>] ? warn_slowpath_common+0x77/0xa3
[  141.444549]  [<ffffffffa026fed7>] ? dahdi_register+0x48/0x321 [dahdi]
[  141.444556]  [<ffffffffa0338f99>] ? hfc_probe+0xab6/0xcc4 [zaphfc]
[  141.444562]  [<ffffffff81062881>] ? do_work_for_cpu+0x0/0x1b
[  141.444568]  [<ffffffff811aedce>] ? local_pci_probe+0x12/0x16
[  141.444571]  [<ffffffff81062881>] ? do_work_for_cpu+0x0/0x1b
[  141.444575]  [<ffffffff8106288c>] ? do_work_for_cpu+0xb/0x1b
[  141.444579]  [<ffffffff810659e1>] ? kthread+0x79/0x81
[  141.444583]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
[  141.444588]  [<ffffffff810d113c>] ? zone_statistics+0x3c/0x5d
[  141.444591]  [<ffffffff81065968>] ? kthread+0x0/0x81
[  141.444594]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
[  141.444597] ---[ end trace 574441bc96749f34 ]---
[  141.444734] vzaphfc: card 0: resetting
[  141.464050] vzaphfc: card 0 configured for TE mode at mem 0xee000000 (0xffffc90009a76000) IRQ 17

Außerdem ist es extrem instabil. Wenn ich Asterisk stop'pe, danach dahdi und dann dahdi start'e, dann resettet sich das System beim Starten von "asterisk" einfach. Sprich ich darf, nachdem zaphfc (oder ein anderes dahdi verwandtes Modul?) einmal geladen ist, es nicht noch einmal neuladen, ansonsten schieße ich mir beim erneuten Starten von asterisk das System ab.

Ich würde mich freuen, wenn jemand von euch vielleicht auch die genaueren Details seiner Konfiguration posten kann. Letzten Endes will ich es einfach nur noch zum Laufen kriegen - und wenn ich dafür sogar asterisk selber compilen muss :-(

Abschließend noch die Versionsnummern der Debian Pakete:
asterisik: 1:1.6.2.9-2+squeeze1
dahdi-linux: 1:2.3.0.1+dfsg-2
dahdi-source: 1:2.3.0.1+dfsg-2
Kernel Paket: linux-image-2.6.32-5-vserver-amd64

Vielen Dank schon einmal für eure Hilfe.

privi · 27 Apr 2011

maeusefaenger schrieb:
Code:

ERROR[3661]: chan_dahdi.c:12393 dahdi_pri_error: 1 Unable to receive TEI from network!

Also die Meldung hab ich mit dem Umschalten von BRI nach BRI_PTMP weg bekommen.

maeusefaenger schrieb:
...
Ein wenig sonderbar ist, dass die Ausgabe von "dahdi_hardware" bei mir leer ist. Ich vermute, das liegt daran, dass die PCI ID meiner ISDN Karte nicht bekannt ist, aber ich denke das hat auf die Funktionsweise des vzaphfc Kernelmoduls keinen weiteren Einfluss?

Das funktioniert bei mir:
root@sip:/usr/local/freeswitch/conf# dahdi_hardware
pci:0000:04:00.0 zaphfc+ 1397:2bd0 HFC-S ISDN BRI card
pci:0000:04:01.0 zaphfc+ 1397:2bd0 HFC-S ISDN BRI card
pci:0000:04:02.0 zaphfc+ 1397:2bd0 HFC-S ISDN BRI card
root@sip:/usr/local/freeswitch/conf#

maeusefaenger schrieb:
Hier die Karte:

Code:

$ lspci -vvvvvv ... 01:07.0 Network controller: Abocom Systems Inc Device 2bd1 (rev 02) Subsystem: Abocom Systems Inc Device 2bd1

Meins:

04:00.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
Subsystem: Advanced Integrations Research Device c101
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 16 (4000ns max)
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at ef00 [disabled]
Region 1: Memory at fdaff000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: vzaphfc

04:01.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
Subsystem: Advanced Integrations Research Device c101
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 16 (4000ns max)
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at ee00 [disabled]
Region 1: Memory at fdafe000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: vzaphfc

04:02.0 Network controller: Cologne Chip Designs GmbH ISDN network controller [HFC-PCI] (rev 02)
Subsystem: Advanced Integrations Research Device c101
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 16 (4000ns max)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at ed00 [disabled]
Region 1: Memory at fdafd000 (32-bit, non-prefetchable)
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: vzaphfc
...

maeusefaenger schrieb:
(Entgegen der Ausgabe von "lspci" heißt das geladene Kernel-Modul "zaphfc" und nicht "vzaphfc").

Gemäß /proc/interrups teilt sich die Karte den Interrupt mit keiner anderen Karte. Die Verkabelung sollte ebenfalls korrekt sein: die Karte ist direkt am NTBA angeschlossen und unter Debian Lenny funktionierte es bisher.

hm... Das sind viele INterrupts bei der Uptime, oder?

root@sip:/usr/local/freeswitch/conf# uptime
14:37:10 up 5:07, 1 user, load average: 0.00, 0.00, 0.00
root@sip:/usr/local/freeswitch/conf# cat /proc/interrupts
CPU0
0: 104 IO-APIC-edge timer
1: 8 IO-APIC-edge i8042
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
14: 87 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 147104327 IO-APIC-fasteoi uhci_hcd:usb5, nouveau, vzaphfc, HDA Intel
17: 147104108 IO-APIC-fasteoi vzaphfc
18: 147104104 IO-APIC-fasteoi uhci_hcd:usb4, vzaphfc
19: 17384 IO-APIC-fasteoi ata_piix, uhci_hcd:usb3, firewire_ohci
20: 0 IO-APIC-fasteoi pata_via
23: 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
27: 21346 PCI-MSI-edge eth0
NMI: 0 Non-maskable interrupts
LOC: 18810938 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
PND: 0 Performance pending work
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
MCE: 0 Machine check exceptions
MCP: 62 Machine check polls
ERR: 0
MIS: 0
root@sip:/usr/local/freeswitch/conf#

maeusefaenger schrieb:
"dahdi_test" läuft fehlerfrei durch mit Werten um die "99.998%".

root@sip:/usr/local/freeswitch/conf# dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.990% 99.993% 99.990% 99.991% 99.991% 99.991% 99.991% 99.990%
99.990% 99.992% 99.991% 99.991% 99.991% 99.990% 99.991% 99.990%
99.990% 99.992% 99.990% 99.991% 99.990% 99.991% 99.991% 99.991%
99.991% 99.991% ^C
--- Results after 26 passes ---
Best: 99.993 -- Worst: 99.990 -- Average: 99.990742, Difference: 100.009258
root@sip:/usr/local/freeswitch/conf#

maeusefaenger schrieb:
Die Debian Quellen vom Paket "dahdi-source" enthalten den Code von der Revision 8 von zaphfc (http://code.google.com/p/zaphfc/source/browse/#svn/branches/2.3/zaphfc). Der einzige Unterschied ist, dass in der base.c vom Debian-Paket in der Funktion "static int hfc_zap_initialize(struct dahdi_hfc *hfccard)" diese Zeile fehlt:

Code:

hfccard->span.owner = THIS_MODULE;

Ansonsten lässt sich über das zaphfc Modul noch sagen, dass es bei mir ebenfalls den "slowpath" Fehler erzeugt:

Code:

[ 141.443783] vzaphfc: HFC-S PCI A ISDN (V1.42) loading [ 141.444371] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 [ 141.444378] alloc irq_desc for 17 on node 0 ... [ 141.444544] [<ffffffff8104e4d4>] ? warn_slowpath_common+0x77/0xa3 ..

Außerdem ist es extrem instabil. ...

Abschließend noch die Versionsnummern der Debian Pakete:
asterisik: 1:1.6.2.9-2+squeeze1
dahdi-linux: 1:2.3.0.1+dfsg-2
dahdi-source: 1:2.3.0.1+dfsg-2
Kernel Paket: linux-image-2.6.32-5-vserver-amd64

root@sip:/usr/local/src/freeswitch# dahdi_cfg -v
DAHDI Tools Version - 2.2.1.1
...
root@sip:/usr/local/src# uname -a
Linux sip 2.6.32-5-amd64 #1 SMP Wed Jan 12 03:40:32 UTC 2011 x86_64 GNU/Linux
root@sip:/usr/local/src# ls -la libpri-1.4.12-beta3.tar.gz
-rw-r--r-- 1 root staff 323534 22. Nov 22:15 libpri-1.4.12-beta3.tar.gz
root@sip:/usr/local/src#

maeusefaenger schrieb:
Vielen Dank schon einmal für eure Hilfe.

Also leider bin ich mittlerweile auch nur noch verzweifelt und ratlos.

Also den slowpath Fehler habe ich auch, scheint aber nur beim starten zu kommen. Desweiteren crashed mein System nach längerer Laufzeit (siehe: http://lists.freeswitch.org/pipermail/freeswitch-users/2011-April/072000.html), und nachdem ein Fax empfangen werden am ISDN Kanal wieder Telefonate gemeldet wenn ich den Port neu initialisiere (siehe: http://lists.freeswitch.org/pipermail/freeswitch-users/2011-April/072001.html)

Ich vermute mal, dass der Patch der bei Debian dabei ist genauso kaputt ist wie alle anderen hfc Lösungen.

Und ich befürchte dass es einfach keine stabilen HFC-S Lösungen mit Freeswitch oder Asterisk gibt. Oder hat jemand eine irgendeine Softwarekonstelation, in der die HFC-S mit Asterisk oder Freeswitch funktioniert? Von mir aus kann es auch eine SuSE von 1980 sein...

maeusefaenger · 28 Apr 2011

privi schrieb:
Und ich befürchte dass es einfach keine stabilen HFC-S Lösungen mit Freeswitch oder Asterisk gibt. Oder hat jemand eine irgendeine Softwarekonstelation, in der die HFC-S mit Asterisk oder Freeswitch funktioniert? Von mir aus kann es auch eine SuSE von 1980 sein...

Mein Debian Lenny mit Asterisk 1.4 lief bisher problemlos. Seit dem dist-upgrade auf Squeeze steht mein VoIP Gateway still.

Ich werde vermutlich meine FritzBox als SIP-Client im Asterisk auf dem Debian Squeeze Server einbinden. Die HFC-Karte ist jetzt jedenfalls schon rausgeflogen damit das System wieder stabil läuft.

sparkie · 29 Apr 2011

privi schrieb:
Oder hat jemand eine irgendeine Softwarekonstelation, in der die HFC-S mit Asterisk oder Freeswitch funktioniert? Von mir aus kann es auch eine SuSE von 1980 sein...

ich habe gerade voriges Wochenende meine Telefonanlage (siehe auch Signatur) auf den offiziellen 'debian squeeze' Stand gebracht. Ich hatte bislang immer mit 'testing' gearbeitet. Danach alle Komponenten fuer chan_lcr (asterisk, mISDN, mISDNuser, chan_lcr) aus der Source gebaut und installiert.

Der chan_lcr laeuft bei mir seit fast einem Jahr produktiv ohne Probleme. Im TE und NT Mode. Alle anderen Varianten, die ich damals ebenfalls getestet habe (dahdi, bristuff, etc) kommen nicht an die Stabilitaet und Funktionalitaet von chan_lcr ran.

siehe auch
#12

man muss sich die Informationen aber zusammensuchen. Es gibt IMHO kein vollstaendiges HOWTO wie man so ein System baut. Die Forumsuche mit <misdn> als Suchbegriff bringt wenigstens schon mal ein paar nuetzliche Infos.

- sparkie

privi · 1 Mai 2011

Also meine Probleme sind jetzt größtenteils beseitigt, nachdem ich mit dem freetdm IRC Channel mehrere Nächte debugged habe. Es scheint als dass vor allem das freetdm von Freeswitch nicht wirklich ausgereift (im Bezug auf die Stabilität) ist.

Folgender Patch bei Freeswitch ist zum GIT vom 30.04.2011 bei mir nötig, dahdi und libpri scheinen grundsätzlich keine großen Probleme zu verursachen, bis auf einen Memoryleak den ich gerade noch genauer beobachte und vermutlich nur beim Neuinitialisieren des PRIs (ftdm stop & ftdm start) und/oder Neustarten von Freeswitch auftreten.

Code:

--- ftmod_libpri.c      2011-05-01 17:30:28.000000000 +0200
+++ ftmod_libpri.c.fixed        2011-05-01 17:31:07.000000000 +0200
@@ -872 +872 @@
-       pri_hangup(spri->pri, pevent->hangup.call, -1);
+       pri_hangup(spri->pri, pevent->hangup.call, PRI_CAUSE_NORMAL_CIRCUIT_CONGESTION);

Falls noch weitere Probleme auftauchen sollten, gebe ich bescheid.

privi · 8 Mai 2011

Im GIT von Freeswitch ist jetzt ein wirklich funktionierender Patch drin, der von mir beschriebene führt zu Problemen und sollte nicht verwendet werden.

Leider habe ich weiterhin das Memory-Leak, das "SUnreclaim" im /proc/memstat steigt leider ins unendliche. Nach drei Tagen nur im Leerlauf sind es bereits über 100 MB:

Code:

root@sip:~# uptime
 23:34:06 up 3 days,  9:48,  1 user,  load average: 0.00, 0.00, 0.00
root@sip:~# cat /proc/meminfo |grep -i reclaim
SReclaimable:      23000 kB
SUnreclaim:       116772 kB
root@sip:~#

Wenn jemand ne Idee hat, kann er sich gerne melden.

sunnyman · 13 Feb 2015

Ich habe zwar keine Idee, aber auf einem aktuellen System das gleiche Problem! Konntest du dein Problem lösen?

Es gibt bei Debian zu dahdi-source auch einen offenen Bug aus 2013, der unser Problem beschreibt:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721147

privi · 13 Feb 2015

Hallo sunnyman,

lustigerweise bin ich seit gestern wieder an der Sache dran, nach einer 2 jährigen Pause, und genau gleichzeitig schreibst Du hierzu was. Wenn ich christlich wäre müsste ich wohl "Gottes Fügung" detektieren. ^^

Bisher konnte ich da Problem nicht lösen, der Bugeintrag von Dir könnte allerdings Gold wert sein. Ich werde mir die base.c anschauen und versuchen auf meinem Testsystem, das ich hier gerade verfügbar habe, das Problem zu beseitigen und ggf. einen Patch hier veröffentlichen.

Ich nutze als Basis allerdings ein anderes Paket: http://sourceforge.net/projects/dahdi-hfcs/

Man müsste sich dann also überlegen wie man dass ins Debian rein bekommt. Den Bug müsste man ja wieder auf machen und den Patch über diesen Weg einreichen können?

Viele Grüße
Markus

sunnyman · 13 Feb 2015

privi schrieb:
Ich nutze als Basis allerdings ein anderes Paket: http://sourceforge.net/projects/dahdi-hfcs/

Hatte ich auch mal genutzt, aber das war im Handling extrem wackelig und führte gerne mal zu Systemabstürzen, wenn man dahdi mal neu gestartet hat oder so.
Auch die Config mit Dahdi hat immer wieder mal Fehler geworfen.
Da bin ich mit

privi schrieb:
Man müsste sich dann also überlegen wie man dass ins Debian rein bekommt. Den Bug müsste man ja wieder auf machen und den Patch über diesen Weg einreichen können?

Der Bug ist ja schlichtweg noch offen, nicht? Ich frage mich gerade aber auch ein bisschen, wo dieser Teil überhaupt herkommt. In den Dahdi-Quellen bei Digium gibts keinen zaphfc mehr. In dahdi-source von Debian schon. Ich setze das Dahdi von openvox ein, dort gibt es auch einen zaphfc.

Ggf. kann man auch mal andere Leute Fragen, eben die von Openvox oder auch Askozia. Ich meine mich aber dunkel zu erinnern, dass Askozia mittlerweile nicht mehr auf Asterisk aufsetzt.

sunnyman · 14 Feb 2015

Ich habe gestern ach mal todesmutig deinen Patch auf die Openvox-Version von Dahdi angewandt. Es gab bei allen zu ändernden Zeilen einen Offset von 21 Zeilen glaub ich, hat aber prima funktioniert.
Bisher scheint auch die Karte (inkl. Speicher) gut zu laufen, ich warte mal noch ein paar Tage ab, bevor ich mich endgültig freue

Debian Squeeze und DAHDI mit HCF

mase

Guest

Neuer User

mase

Guest

Neuer User

mase

Guest

Neuer User

mase

Guest

Neuer User

mase

Guest

Neuer User

Neuer User

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Aktives Mitglied

Statistik des Forums