[gelöst] D-Channel Problem mit Asterisk + Sirrix PCI4S0

[Szony]

Hallo Forengemeinde,

bevor ich mit irgend etwas anfangen werde möchte ich mich bei uch für die vielen hilfreichen Tipps und Antworten bedanken, die dazu begetragen haben, dass mein Asterisk läuft.
Der Asterisk mit einer Sirrix-PCI4S0 hängt am internen S0 einer Alcatel 4400 - Telefonanlage und soll hauptsächlich als Voicemail-Maschine eingesetzt werden. Testweise sind auch ein paar SIP-Teilnehmer eingereichtet um innerhalb des Hausnetztes telefonieren zu können.
Die Voicemail mit allen Funktionen und auch die SIP-Gespräche laufen problemfrei.

Aber nun das Problem - der Asterisk läuft nicht stabil.

Nach unterschiedlich langer Laufzeit (im Schnitt etwa zwei Stunden) bekomme ich einen der beiden folgenen Fehler in den Logfiles "/var/log/messages" und "/var/log/warn":

• sirrix ipac (0): D-channel received empty frame, discarding frame
• sirrix ipac (0): D-channel receive data overflow, discarding frame (RSTAD=0xc)

Danach läuft alles noch im Schnitt eine Stunde weiter und der Fehler tritt erneut auf, woraufhin der Asterisk nicht mehr funktionstüchtig ist. Am Telefon bekomme ich die Meldung "Link ausser Betrieb" beim Versuch die Voicemail zu anzurufen.

Ein Neustart des Asterisk und auch das entladen und neuladen der Sirrix-Treiber bringt keine Abhilfe. Es hilft nur ein Server-Neustart, was im produktiven Betrieb natürlich absolut unpraktikabel ist.

Das >> hier << beschrieben D-Channel-Dump bricht genau an der Stelle ab, wenn ein leeres Frame oder der data overflow reinkommt.

Hat jemand schon mal ein ähnliches Problem gehabt?
Oder eine Idee warum diese D-Channel Fehler auftauchen?
Kann es sein, dass der Fehler von der Telefonanlage kommt?
Oder hab ich einen Fehler in meiner sirrix.conf, die diesen Fehler verursacht?

sirrix.conf

[Global]
internationalprefix = 00
nationalprefix = 0

;Eingehende Anrufe
[Incomming]
ports = 0000		; 1. Karte, 1. Port
mode = TE	       ; TE Mode da die Karte an einem S0 Bus
ptp = yes		  ; Anlagenanschluss
master = yes		; Port arbeitet als Master
number = +		 ; Angerufene Nummer
extension = +		; Anzurufenden Extension
callerid = <+>		; CallerID von eingehenden Anrufen
show_cidname = yes		; Anrufernamen zeigen
country = de		; Land
language = de		; Sprache

;Abgehende Anrufe
&#91;Outgoing&#93;
ports = 0000		; 1. Karte, 1. Port
mode = TE		; TE Mode da die Karte an einem S0 Bus
ptp = yes		; Anlagenanschluss
master = yes		; Port arbeitet als Master
number = +		; Angerufene Nummer
extension = 		; Anzurufenden Extension
callerid = +		; CallerID von ausgehenden Anrufen
cfnotify = no
cfu = no
cfnr = no
cfb = no
aocd = no
colp = no
redir = no
notify = yes
echocancel = yes
providetones = yes

Ich bin für jede Hilfe extrem dankbar.

Mfg Szony

[sirrix]

Hallo!

Hallo Forengemeinde,

• sirrix ipac (0): D-channel received empty frame, discarding frame
• sirrix ipac (0): D-channel receive data overflow, discarding frame (RSTAD=0xc)

Ein Neustart des Asterisk und auch das entladen und neuladen der Sirrix-Treiber bringt keine Abhilfe. Es hilft nur ein Server-Neustart, was im produktiven Betrieb natürlich absolut unpraktikabel ist.

Hmmm ... bei einem Entladen und Laden der Kernel-Module werden die Ports komplett resettet, sind also im gleichen Zustand wie nach einem Reboot. Mit "rmmod sirrix_pfic" und "modprobe sirrix_pfic" sollte es eigentlich gehen, wenn es ein Port-(SW-)Fehler wäre.

Die sirrix.conf ist ok. Ich würde folgendes mal machen um den Fehler eingrenzen zu können:

• einen anderen Port benutzen
• Verkablung prüfen
• andere Kabel benutzen

Viele Grüße,
Oskar.

[Szony]

Danke für die Hinweise.

Ohne das ich gestern noch etwas verändert habe ist der Asterisk diese Nacht seltsamerweise durchgelaufen (und immer noch funktionstüchtig), trotz dass wieder zwei mal die Meldung "sirrix ipac (0): D-channel received empty frame, discarding frame" aufgetreten ist.
Ich kann ihn immer noch anrufen und SIP-Gespräche werden Hausintern weitervermittelt.

Heute morgen habe ich die Verkabelung nochmals überprüft und alles war noch in bester Ordnung.
Danach habe ich testweise den Port gewechseln und nutze nun den zweiten statt den ersten Port.
Mal sehen ob der Asterisk Montag immer noch erreichbar ist.

Mfg Szony

[Szony]

Das wochenende ist um und es konnten wieder neue Erkenntnoisse gewonnen werden. Der Asterisk ist nicht mehr zu verwenden, aber ich glaube ein Muster erkannt zu haben, zu welchen Zeitpunkten der Abstutz kommt.
Ich vermute es hat nicht direkt etwas mit dem D-Channel zu tun, sondern eher mit dem Multi-Prozessor, der in dem Server hängt.

Hier ein Auszug aus "/var/log/messages"

Aug 12 13:17:18 laura kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 12 13:17:18 laura kernel:  printing eip:
Aug 12 13:17:18 laura syslog-ng[1490]: STATS: dropped 0
Aug 12 13:17:18 laura kernel: f8a8faf0
Aug 12 13:17:18 laura kernel: *pde = 00000000
Aug 12 13:17:18 laura kernel: Oops: 0000 [#1]
Aug 12 13:17:18 laura kernel: PREEMPT SMP 
Aug 12 13:17:18 laura kernel: Modules linked in: sirrix_bch sirrix_pfic sirrix_base
Aug 12 13:17:18 laura kernel: CPU:    1
Aug 12 13&#58;17&#58;18 laura kernel&#58; EIP&#58;    0060&#58;&#91;<f8a8faf0>&#93;    Not tainted VLI
Aug 12 13&#58;17&#58;18 laura kernel&#58; EFLAGS&#58; 00010206   &#40;2.6.12.3&#41; 
Aug 12 13&#58;17&#58;18 laura kernel&#58; EIP is at ipac_handle_interrupt_icd+0x580/0x7e0 &#91;sirrix_base&#93;
Aug 12 13&#58;17&#58;18 laura kernel&#58; eax&#58; 000000c0   ebx&#58; 00000000   ecx&#58; c1836090   edx&#58; c1ba4b40
Aug 12 13&#58;17&#58;18 laura kernel&#58; esi&#58; f66ae1d8   edi&#58; f66ae1e0   ebp&#58; f66ae1d8   esp&#58; c18dbf10
Aug 12 13&#58;17&#58;18 laura kernel&#58; ds&#58; 007b   es&#58; 007b   ss&#58; 0068
Aug 12 13&#58;17&#58;18 laura kernel&#58; Process events/1 &#40;pid&#58; 7, threadinfo=c18da000 task=c18baa40&#41;
Aug 12 13&#58;17&#58;18 laura kernel&#58; Stack&#58; 000007c0 6dae52d2 0000533d c183a530 f606fa40 00000202 c18dbf8c c18dbf1f 
Aug 12 13&#58;17&#58;18 laura kernel&#58;        f66ae228 c1836080 f66ae22c f66ae1d8 c012cba9 f66ae1d8 c18dbf6c 00000000 
Aug 12 13&#58;17&#58;18 laura kernel&#58;        c18360a8 f8a8f570 00000202 c18da000 c1836090 ffffffff ffffffff 00000001 
Aug 12 13&#58;17&#58;18 laura kernel&#58; Call Trace&#58;
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c012cba9>&#93; worker_thread+0x1c9/0x260
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<f8a8f570>&#93; ipac_handle_interrupt_icd+0x0/0x7e0 &#91;sirrix_base&#93;
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c0116bf0>&#93; default_wake_function+0x0/0x20
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c0116bf0>&#93; default_wake_function+0x0/0x20
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c012c9e0>&#93; worker_thread+0x0/0x260
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c013147d>&#93; kthread+0xbd/0x100
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c01313c0>&#93; kthread+0x0/0x100
Aug 12 13&#58;17&#58;18 laura kernel&#58;  &#91;<c0101075>&#93; kernel_thread_helper+0x5/0x10
Aug 12 13&#58;17&#58;18 laura kernel&#58; Code&#58; 30 a9 f8 89 44 24 04 e8 1f bf 68 c7 ff 86 20 01 00 00 e9 c4 fb ff ff 8b 5e 34 c6 44 24 1c 1f 8d b6 00 00 00 00 8d bf 00 00 00 00 <0f> b6 03 43 8b 16 89 44 24 0c 31 c0 89 44 24 08 0f b6 46 04 89

Diese Meldung bekomme ich, wenn ich jetzt versuche den Sirrix-Treiber zu entladen.

laura:~ # rmmod sirrix_pfic
ERROR: Removing 'sirrix_pfic': Device or resource busy

Ich bin da leider überfragt und sowohl die Suche hier im Forum als auch google konnten mir da noch nicht weiterhelfen.
Hat jemand von euch evtl eine Idee wo ich hier bei der Fehlersuche ansetzen kann?

[stevie]

Könnte tatsächlich ein SMP-Problem sein! Schon mal Sirrix kontaktet?
Ansonsten vielleicht noch eine andere Möglichkeit:
Du schreibst, der * hinge am internen S0 der TK-Anlage!
Kann es sein, daß Deine TK-Anlage einen Bug hat und ab und zu tatsächlich diese "korrupten Frames" schickt?? Könntest ja mal versuchen, (wenn der Aufwand für's umkonfigurieren nicht zu hoch ist), den * mal direkt an ein T-Com-Amt zu hängen und prüfen, ob der Fehler dann immer noch auftaucht!
Sind nur so meine spontanen Gedanken...bin ja selber noch *-Neuling!
Grüße
Stevie

[Szony]

Den Asterisk direkt an ein T-Com-Amt zu hängen ist kein Problem, das müssten wir nur umstecken. Das hat mir ein Kollege aus dem Telefonbereich schon eingerichtet.

Derzeit probieren wir allerdings erst noch einen 2.4er Kernel, evtl hängt es ja auch dadran.

[stevie]

Welche Kernel-Version setzt Du denn z.Zt. genau ein??
........nur mal so für die Allgemeinbildung!
Grüße
Stevie

[Szony]

Die "funktionierende" 2.6er Version ist meiner Signatur zu entnehmen. Das ist leider die bei der der oben genannt Systemcrash immer auftritt.

Aktuelle versuche ich mich an der Kernel-Version 2.4.31.

[Szony]

Der Kernel 2.4.31 hat leider auch nicht geholfen. Werden wir also mal den Astertisk direkt am T-Com-Amt testen um andere Fehler auszuschließen.

[stevie]

Hast Du den Kernel wieder mit SMP-Support compiliert?
Ich würde mal nur Single-Proz-Support versuchen! Das Verhalten bez. des Interrupt-Handlings eines Linux-Systems ist stark unterschiedlich zwischen Single- und Multi-Proz-Systemen! Einfach mal mit beiden Kernel-Versionen testen!

[Szony]

Vielen Dank Stevie, dass war der entscheidende Tipp. Nachdem der Kernel ohne Multi-Prozessor-Unterstützung kompiliert wurde läuft der Asterisk fehlerfrei.

Es scheint, dass die Sirrix-Karte sich nicht mit unserem Multi-Prozessoren-System verträgt, aber evtl kann Oskar von Sirrix dazu ja meghr sagen.

Unser Problem ist jedenfalls gelöst.

Mfg,
Szony

[stevie]

Prima!! Freut mich, wenn es geholfen hat! Jetzt stellt sich die Frage: Verträgt sich die Karte/der Treiber z.Zt. grundsätzlich nicht mit SMP-Systemen oder gibt es "nur" ein Problem mit bestimmten Chipsätzen? Wäre natürlich schon toll, wenn SMP funktionieren würde, da das komplette codieren und decodieren beim * in SW (also auf der CPU) gemacht wird. Da wäre "die Kraft der zwei Herzen" bei größeren Installationen natürlich eine große Hilfe!
Welchen Chipsatz verwendest Du denn?
Grüße
Stevie

[Maik]

Prima!! Freut mich, wenn es geholfen hat! Jetzt stellt sich die Frage: Verträgt sich die Karte/der Treiber z.Zt. grundsätzlich nicht mit SMP-Systemen oder gibt es "nur" ein Problem mit bestimmten Chipsätzen?

AFAIK ist es ein Treiber-Problem. Da gibt es wohl immer noch irgendwo ne race condition.

Wäre natürlich schon toll, wenn SMP funktionieren würde, da das komplette codieren und decodieren beim * in SW (also auf der CPU) gemacht wird. Da wäre "die Kraft der zwei Herzen" bei größeren Installationen natürlich eine große Hilfe!

Wieviele Kanaele bedient denn dein Server und in welchen codec codierst du denn? Bisher bin ich noch immer gut mit Single-Prozessor Systemen ausgekommen (trotz S2M-Leitung).

[stevie]

Es ging nicht konkret um meinen Anwendungsfall! Sondern einfach darum, daß es schade wäre, wenn man dies Option eines SMP-Systems nicht nutzen könnte!
Will ja jetzt hier keine theoretische Diskussion lostreten, aber wieviele gleichzeitige Verbindungen muss Dein * denn auf Deiner S2M-Leitungen so bedienen? Und von "wo" nach "wo" muss er dabei de/codieren? Ich finde die Frage in so fern spannend, weil die Aussagen, was der * so an CPU-Leistung benötigt, ja teilweise sogar widersprüchlich sind.
Grüße
Stevie

[Maik]

Konkrete Zahlen kann ich dir hier nicht nennen. Ich kann nur sagen, dass die meisten Leute den Bedarf an Rechenleistugn einfach ueberschaetzen. Oft werden die meisten Kanaele nur im LAN genutzt und daher ist auch keine Komprimierung notwendig (sogar eher stoerend). Fuer die paar Kanaele die dann noch uebrig bleiben reicht ein P4 locker aus.