mISDN, Fehlermeldungen, Abstürze, Verzweiflung

Hallo,
ich experimentiere gerade mit 2 HFC-Karten in einem Rechner rum und drehe langsam durch.
Eine Karte läuft im nt_ptp=1 die andere te_ptmp=2. An der Karte 1 ist eine Telefonanlage angeschlossen, Anlagenanschluß. Ich habe es sowohl mit einer SVN-installierten und auch mit einer "install-misdn-mqueue"-Version probiert.

Beides war irgendwie nicht das Gelbe vom Ei.
Die svn-Version gibt beim Starten von Asterisk folgende Fehlermeldung:
----------------------
Feb 22 11:02:17 WARNING[2844]: misdn_config.c:635 _build_port_config: misdn.conf: "msn=*" (section: intern) invalid or out of range. Please edit your misdn.conf and then do a "misdn reload".
----------------------
Durchtelefonieren und Testanrufe gehen allerdings erst nach dem 2ten Start von Asterisk. Frisch nach dem Booten gestartet, veraschiedet es sich gleich wieder. Nochmal gestartet gehts.

Ein "misdn reload" verabschiedet sich mit einem:
----------------
*CLI> misdn reload
Reloading mISDN Config
Feb 22 11:08:02 WARNING[2887]: chan_misdn.c:4222 chan_misdn_log: Dynamic Crypting Activation is not support during reload at the moment
Speicherzugriffsfehler
----------------

Thema 2, die misdn-install-mqueue-Version macht folgendes, eine Badness:
---------------------
Feb 21 19:55:19 localhost kernel: Badness in __kfree_skb at net/core/skbuff.c:334
Feb 21 19:55:19 localhost kernel: [<c020bc83>] __kfree_skb+0x83/0xb7
Feb 21 19:55:19 localhost kernel: [<c4907172>] hfcpci_interrupt+0x62f/0x7a1 [hfcpci]
Feb 21 19:55:19 localhost kernel: [<c011864f>] profile_tick+0x27/0x49
Feb 21 19:55:19 localhost kernel: [<c0130f9f>] handle_IRQ_event+0x20/0x4c
Feb 21 19:55:19 localhost kernel: [<c013104a>] __do_IRQ+0x7f/0xe9
Feb 21 19:55:19 localhost kernel: [<c010521b>] do_IRQ+0x1b/0x28
Feb 21 19:55:19 localhost kernel: [<c0103c7a>] common_interrupt+0x1a/0x20
Feb 21 19:55:19 localhost kernel: [<c0101047>] default_idle+0x2b/0x53
Feb 21 19:55:19 localhost kernel: [<c01010ca>] cpu_idle+0x47/0x70
Feb 21 19:55:19 localhost kernel: [<c02ee692>] start_kernel+0x14d/0x14f
------------

Kernelversion ist bei allen Experimenten 2.6.15.4 auf Debian 3.1 (sarge).

Vielen Dank für Deine schnelle Hilfe! Das finde ich klasse das man hier direkt einen Entwickler zur Verfügung hat, dann machts doch noch richtig Spaß!

crich schrieb:

die Option heisst msns , also das finale s hat gefehlt. Der

Zum Vergrößern anklicken....

Tatsächlich, wohl etwas geschlampt beim Eintragen.

crich schrieb:

Speicherzugriffsfehler beim reload ist seit gestern behoben, sollte eigentlich nicht mehr auftreten.

Zum Vergrößern anklicken....

Wie kann ich sicherstellen, das die aktuellste Version auch benutzt und nicht nur geladen wird?
Ich habe gerade alles nochmal neu ge-make-ed und bekomme jetzt bei misdn show config auch Version rc21 angezeigt, das war gestern noch rc20.

crich schrieb:

Du solltest mal das hfcpci modul in die Blacklist vom Hotplug System von

dann neu-booten. Hoffe das hilft dir.

Zum Vergrößern anklicken....

Scheint etwas besser zu gehen.

Just for info:
Ich habe hier noch ein seltsames Phänomen in der Telefonanlage am internen ISDN (Panasonic KX-TD-208G). Ein Anruf vom Asterisk auf einen Anschluss an der Telefonanlage wird stark verzögert signalisiert. Es klingelt erst nach 15-30 Sekunden. Diesen Fehler trat aber auch auf, als ich die Telefonanlage an einer Fritzbox 7050 hatte, das ist also offensichtlich ein Bug in der Anlage.

crich schrieb:

du kannst mal einen Trace mit misdn ziehen, einfach debug=4 und tracefile=/var/log/misdn.trace in [general] in misdn.conf eintragen und dann einen rufversuchen auf dei anlage machen.

Zum Vergrößern anklicken....

Habe ich jetzt mal gemacht, es sieht so aus, als ob die Telefonanlage nach der Signalisierung seitens mISDN erstmal eine Denkpause einlegt, im Logfile ist eine Lücke von 15-30 Sekunden bis etwas von der Anlage zurückkommt. Ändern kann man es wohl eh kaum, die Anlage wird nicht mehr supportet, is auch wurscht, ich habe das erstmal ausprobieren wollen, später kommt das an eine Alcatel-Telefonanlage.

Das werde ich die Tage testen, wie kann ich einen Beitrag leisten damit rc21 stable wird?

Gehen Faxe eigentlich durch, im "bridging mode"?

crich schrieb:

die rc21 wird nicht stable, ich bringe im moment fast täglich neue Release Candidaten raus.

Zum Vergrößern anklicken....

Sorry, da hatte ich mich missverständlich ausgedrückt. Ich meinte natürlich die 0.3.0.

crich schrieb:

Du kannst helfen in dem du immer fleissig testest

Zum Vergrößern anklicken....

Dann werde ich die nächsten Tage mal die Leitung kräftig quälen.

Erster Test an Alcatel

sterkel schrieb:

Dann werde ich die nächsten Tage mal die Leitung kräftig quälen.

Zum Vergrößern anklicken....

Hallo,
gestern konnte ich dank Karnevalsruhe das ganze erstmals an der Alcatel und am "Original" Anlagenanschluß von T-Com testen. Es funktionierte schon sehr gut, es lohnt sich also!Man kann durchtelefonieren, wunderbar.

Es gab folgende Meldungen im Syslog:

------------------
Feb 23 16:22:02 localhost kernel: release instance class dev inst-50010101
Feb 23 16:22:11 localhost kernel: l2mgr: prim 23082 I
Feb 23 16:22:15 localhost kernel: l2mgr: prim 23082 G
Feb 23 16:22:19 localhost kernel: l2mgr: prim 23082 F
Feb 23 16:22:21 localhost last message repeated 2 times
Feb 23 16:22:24 localhost kernel: isdnl2 try overwrite ack queue entry 0
Feb 23 16:22:28 localhost kernel: l2mgr: prim 23082 I
Feb 23 16:22:32 localhost kernel: l2mgr: prim 23082 G
Feb 23 16:22:35 localhost kernel: release instance class dev inst-50010100
Feb 23 16:22:35 localhost kernel: release instance class dev inst-50010101
Feb 23 16:22:35 localhost kernel: dev_manager prim f1780 not handled
Feb 23 16:22:35 localhost kernel: release instance class dev inst-50010102
Feb 23 16:22:43 localhost kernel: l2mgr: prim 23082 F
Feb 23 16:22:45 localhost last message repeated 2 times
------------------

und haufenweise solche:

Feb 23 16:12:36 localhost kernel: channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)