Bei bridging stürzt der komplette Rechner ab

klimpel.b · 30 Mai 2006

Hallo,

ich habe ein Problem mit dem Hardware bridging des misdn Treibers.

Wenn ich bridging=yes in der misdn.conf setzt stürzt der komplette Rechner ab sobald ich das Gespräch aufnehmen.

Dies ist ein Ausschnitt des Gespräches, ich wähle von einem Telefon(Msn 21) die 22 an und dann klingelt es ganz normal wie immer nur wenn ich bei der 22 abhebe höre ich nichts auf beiden Seiten und der Rechner hängt sich auf.

Code:

P[ 4]  --> screen:0 --> pres:0
P[ 4]  --> channel:1 caps:Speech pi:0 keypad:
P[ 4]  --> urate:0 rate:16 mode:0 user1:0
P[ 4]  --> pid:12 addr:50010402 l3id:10040
P[ 4]  --> b_stid:10010400 layer_id:50010480
P[ 4]  --> bc:81a42fc h:0 sh:0
P[ 4] $$$ bc already upsetted stid :10010400 (state:BCHAN_ACTIVATED)
P[ 4] Sending Control ECHOCAN_ON taps:128 training:500
P[ 4] Taps is 128
P[ 4] bchannel_activate: BC Not properly upsetted (state:BCHAN_ACTIVATED) addr:50010402
    -- Attempting native bridge of mISDN/4-u11 and mISDN/4-u12
P[ 4] Disabling Echo Cancellor when Bridged
P[ 4] Disabling Echo Cancellor when Bridged
P[ 4] I SEND: Making conference with Number:25
P[ 4] I Send: BRIDGE from:4 to:4
P[ 4]  --> bc_addr:50010402
P[ 4] BC_STATE_CHANGE: from:BCHAN_ACTIVATED to:BCHAN_BRIDGED
P[ 4] Joining bc:50010402 in conf:25
P[ 4]  --> bc_addr:50020402
P[ 4] BC_STATE_CHANGE: from:BCHAN_ACTIVATED to:BCHAN_BRIDGED
P[ 4] Joining bc:50020402 in conf:25
P[ 4] * Makeing Native Bridge between 21 and 21
easyasterisk*CLI>

Als Kernel benutze ich 2.6.14.1
Als Isdn Hardware benutze ich die Karte HFC-4S

Dies sind die letzen ausgaben des /var/log/misdn.trace Datei

Code:

Tue May 30 12:55:13 2006: P[ 4]   --> channel:1 caps:Speech pi:0 keypad:
Tue May 30 12:55:13 2006: P[ 4]   --> urate:0 rate:16 mode:0 user1:0
Tue May 30 12:55:13 2006: P[ 4]   --> pid:12 addr:50010402 l3id:10040
Tue May 30 12:55:13 2006: P[ 4]   --> b_stid:10010400 layer_id:50010480
Tue May 30 12:55:13 2006: P[ 4]   --> bc:81a42fc h:0 sh:0
Tue May 30 12:55:13 2006: P[ 4]  $$$ bc already upsetted stid :10010400 (state:BCHAN_ACTIVATED)
Tue May 30 12:55:13 2006: P[ 4]  Tone Indicate:
Tue May 30 12:55:13 2006: P[ 4]   --> Ring
Tue May 30 12:55:13 2006: P[ 4]  misdn_write: zero write
Tue May 30 12:55:13 2006: P[ 4]   --> * SEND: State Ring pid:12
Tue May 30 12:55:13 2006: P[ 4]  BCHAN: MGR_SETSTACK|IND
Tue May 30 12:55:13 2006: P[ 4]   --> Got Adr 50020402
Tue May 30 12:55:13 2006: P[ 4]  BC_STATE_CHANGE: from:BCHAN_SETUP to:BCHAN_SETUPED
Tue May 30 12:55:13 2006: P[ 4]  $$$ Bchan Activated addr 50020402
Tue May 30 12:55:13 2006: P[ 4]  BC_STATE_CHANGE: from:BCHAN_SETUPED to:BCHAN_ACTIVE
Tue May 30 12:55:13 2006: P[ 4]  BC_STATE_CHANGE: from:BCHAN_ACTIVE to:BCHAN_ACTIVATED
Tue May 30 12:55:13 2006: P[ 4]  BCHAN: bchan ACT Confirm
Tue May 30 12:58:09 2006: P[ 0]  -- mISDN Channel Driver Registred -- (BE AWARE THIS DRIVER IS EXPERIMENTAL!)

Boesl · 1 Jun 2006

Hallo,

ich kann dir zwar nicht helfen, aber ich muss mich dir anschließen.
Ich habe eine BeroNet BN4S0 und einen gentoo-2.6.16 kernel und auch bei mir stürtzt das System ab bei bridging=yes. Hilfe wäre echt gut, denn warum in Software verbinden, wenn es in Hardware geht..

Gruß
Boesl

klimpel.b · 1 Jun 2006

hi, ist es also bei dir genauso wie ich es beschrieben habe? Vieleicht postest du auch mal bei einem absturzt die misdn.trace ausgaben.

Mfg Benjamin

Boesl · 1 Jun 2006

Ok, das ist mein Output in der misdn.trace:

Code:

Thu Jun  1 18:07:30 2006: P[ 1]  I IND :ALERTING oad:403xxxx dad:498xxxx
Thu Jun  1 18:07:30 2006: P[ 1]   --> mode:TE cause:16 ocause:16 rad: cad:
Thu Jun  1 18:07:30 2006: P[ 1]   --> facility:FAC_NONE out_facility:FAC_NONE
Thu Jun  1 18:07:30 2006: P[ 1]   --> info_dad: onumplan:0 dnumplan:0 rnumplan:0 cpnnumplan:0
Thu Jun  1 18:07:30 2006: P[ 1]   --> screen:1 --> pres:0
Thu Jun  1 18:07:30 2006: P[ 1]   --> channel:1 caps:Audio 3.1k pi:8 keypad:
Thu Jun  1 18:07:30 2006: P[ 1]   --> urate:0 rate:16 mode:0 user1:0
Thu Jun  1 18:07:30 2006: P[ 1]   --> pid:24 addr:50010102 l3id:50005
Thu Jun  1 18:07:30 2006: P[ 1]   --> b_stid:10010100 layer_id:50010180
Thu Jun  1 18:07:30 2006: P[ 1]   --> bc:81774fc h:0 sh:0
Thu Jun  1 18:07:30 2006: P[ 1]   --> bc_state:BCHAN_ACTIVATED
Thu Jun  1 18:07:30 2006: P[ 4]  * IND : Indication [3] from outdial498xxxx
Thu Jun  1 18:07:30 2006: P[ 4]   --> * IND :	ringing pid:23
Thu Jun  1 18:07:30 2006: P[ 4]  I SEND:ALERTING oad:101 dad:0498xxxx 
Thu Jun  1 18:07:30 2006: P[ 4]   --> bc_state:BCHAN_ACTIVATED
Thu Jun  1 18:07:30 2006: P[ 4]   --> mode:NT cause:16 ocause:16 rad: cad:
Thu Jun  1 18:07:30 2006: P[ 4]   --> facility:FAC_NONE out_facility:FAC_NONE
Thu Jun  1 18:07:30 2006: P[ 4]   --> info_dad:9 onumplan:0 dnumplan:  rnumplan:  cpnnumplan:0
Thu Jun  1 18:07:30 2006: P[ 4]   --> screen:1 --> pres:0
Thu Jun  1 18:07:30 2006: P[ 4]   --> channel:1 caps:Audio 3.1k pi:3 keypad:
Thu Jun  1 18:07:30 2006: P[ 4]   --> urate:0 rate:16 mode:0 user1:0
Thu Jun  1 18:07:30 2006: P[ 4]   --> pid:23 addr:50010402 l3id:10040
Thu Jun  1 18:07:30 2006: P[ 4]   --> b_stid:10010400 layer_id:50010480
Thu Jun  1 18:07:30 2006: P[ 4]   --> bc:81b6834 h:0 sh:0
Thu Jun  1 18:07:30 2006: P[ 4]  $$$ bc already upsetted stid :10010400 (state:BCHAN_ACTIVATED)
Thu Jun  1 18:07:30 2006: P[ 4]  Tone Indicate:
Thu Jun  1 18:07:30 2006: P[ 4]   --> Ring
Thu Jun  1 18:07:30 2006: P[ 4]  misdn_write: zero write
Thu Jun  1 18:07:30 2006: P[ 4]   --> * SEND: State Ring pid:23
Thu Jun  1 18:07:30 2006: P[ 1]  Set State Ringing
Thu Jun  1 18:07:30 2006: P[ 1]  bchannel_activate: BC Not properly upsetted (state:BCHAN_ACTIVATED) addr:50010102

klimpel.b · 7 Jun 2006

Hallo,

hab den Fehler nun gefunden, war aber bei voip-info.org beschrieben);

Im Kernel muss PROFILING ausgeschaltet werden.

Mfg Benjamin

crich · 8 Jun 2006

Hallo Leuts,

tatsächlich gabs diese Profiling problematik, ich habe aber im neuesten mISDN einen Fix dafür gemacht, inzwischen drüfte es beim bridgen nicht mehr abstürzen..

Boesl · 8 Jun 2006

Hallo,

also ich habe Neuigkeiten, ich habe heute eine neue Version von chan_misdn runtergeladen und mit der scheint es zu gehen.
Ich kann jetzt in der misdn.conf->bridging=yes eintragen und es stürz nichts mehr ab, allerdings lag es nicht am Profiling, das war eh aus.

Jetzt habe ich aber noch eine Frage, wie spielen der Parameter

- misdn.conf->bridging=yes
und
- /etc/misdn-init->dsp_options=0 (0 oder 2 für das modul misdn_dsp)
zusammen??
Und wie bekomme ich jetzt raus ob er in HW bridging macht??

Gruß
Boesl

crich · 8 Jun 2006

prima!

du kannst beim dsp modul den debug=0x10 wert setzen, dann bekommst du aufschluss über die bridging art, im syslog output.

lo4dro · 9 Jun 2006

Hallo.

So ich melde mich auch mal wider.

Ich hab auch mit den neusten misdn und chan misdn Treiber das Probleme das der Kernel einfriert, sobald ich ein Gesprach von einer Karte zur nächsten Karte (bridging) nutze.
In meiner misdn.conf hab ich [general] "bridging = yes" eingetragen.
Werde das ganze bei einer ruhigen Minute mal mit "bridging = no" Testen.
Bis zu chan_misdn-0.3.0-rc27 hat die Einstellung "bridging = yes" sehr gut funktioniert.

Boesl · 9 Jun 2006

@crich
im syslog ist nichts zu sehen, ob HW oder SW nur folgendes:

Code:

Jun  9 09:26:47 [kernel] DSP_CANCEL_INIT called
Jun  9 09:26:52 [kernel] mISDN: INTERNAL ERROR in /root/misdn/mISDN/drivers/isdn/hardware/mISDN/stack.c:512 double clearing

Das ist alles was kommt beim Anruf
und beim laden der module:

Code:

Jun  9 09:48:51 [kernel] CAPI Subsystem Rev 1.1.2.8
Jun  9 09:48:51 [kernel] capifs: Rev 1.1.2.3
Jun  9 09:48:51 [kernel] capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
Jun  9 09:48:52 [kernel] Modular ISDN Stack core $Revision: 1.34 $
Jun  9 09:48:52 [kernel] ISDN L1 driver version 1.16
Jun  9 09:48:53 [kernel] ISDN L2 driver version 1.27
Jun  9 09:48:53 [kernel] mISDN: DSS1 Rev. 1.38
Jun  9 09:48:53 [kernel] mISDN_dsp: Audio DSP  Rev. 1.17 (debug=0x10) EchoCancellor MG2
Jun  9 09:48:53 [kernel] mISDN Capi 2.0 driver file version 1.19
Jun  9 09:48:53 [kernel] mISDN: HFC-multi driver Rev. 1.41
Jun  9 09:48:53 [kernel] hfcpci_probe: DIPs(0x8f) jumpers(0xc)
Jun  9 09:48:53 [kernel] layer2: Windowsize 1

Also leider sagt mir das nix über HW oder SW aus.. nur das es da noch ein Fehler gibt...

Gruß
Boesl

crich · 10 Jun 2006

Boesl:

Ich schätze du setzt eine Version <0.3.1-rc10 ein. Bitte mach mal ein upgrade auf rc10, dann sollte die "double clearing .." Meldung weg sein.

Ich habe in deinem output gesehen, dass du dem dsp debug=0x10 übergibst.. vielleicht landet dein Kernel output auch in der /var/log/kern.log oder in /var/log/messages

Boesl · 10 Jun 2006

Hallo,

wenn mich nicht alles täuscht, ist die Version genau die rc10, aber ich werde das am Montag gleich noch mal testen.

Und ok, ich werde mal alle log durch suchen, aber in welchem "sollte" es denn auftauchen, im misdn.trace? oder syslog oder....?

Gruß
Boesl

Boesl · 12 Jun 2006

Hallo,

also mit der rc10 hattest du recht, die Meldung ist nun weg.

Zu den Logs kann ich nur sagen, das ich im System nix finden kann, aber im Ast. Output habe ich die Zeile "P[ 4] * Making Native Bridge between 101 and 102" gefunden, ich weiß nicht ob das jetzt die Meldung von mISDN_dsp ist, aber vieleicht?

Gruß
Boesl

crich · 13 Jun 2006

ist nicht die Meldung vom mISDN_dsp sondern vom chan_misdn..

die dsp meldungen enthalten Ausdrücke wie :"slot_rx" und "bank_rx" usw.. aber wie gesagt, du must dazu das mISDN_dsp modul mit der debug=0x10 Option laden.

Das kannst du sogar während asterisk läuft machen, dazu darf aber keiner telefonieren, mach dann einfach:

modprobe -r mISDN_dsp
modprobe mISDN_dsp=0x10

Boesl · 13 Jun 2006

Hallo,
ich habe es endlich gefunden, das metalog System hatte scheinbar einen Bug, es wurden keine Nachrichten mit KERN_INFO mehr nach der ersten Meldung von mISDN_dsp geloggt, aber nach einem Update des System kammen alle Ausgaben...

Ich habe sie hier mal angehängt und hoffe (@crich) du kannst mir sagen ob HW oder SW bridging? Ich denke ja, aber bin mir mit den Ausgaben nicht so sicher.

Code:

Jun 13 15:57:56 [kernel] mISDN_dsp: Audio DSP  Rev. 1.17 (debug=0x10) EchoCancellor MG2 dsp_debug: 16, DEBUG_DSP_CMX: 16, result: 16
Jun 13 15:57:56 [kernel] mISDN_dsp: DSP clocks every 80 samples. This equals 1 jiffies.
Jun 13 15:58:08 [kernel] dsp_cmx_hardware checking dsp DSP_S4/C1
Jun 13 15:58:08 [kernel] cmx_receive(dsp=df3d9000): UNDERRUN (or overrun), adjusting read pointer! (inst DSP_S4/C1)
Jun 13 15:58:08 [kernel] cmx_receive(dsp=df3d9000): UNDERRUN (or overrun), adjusting read pointer! (inst DSP_S4/C1)
Jun 13 15:58:16 [kernel] dsp_cmx_hardware checking dsp DSP_S1/C1
Jun 13 15:58:16 [kernel] cmx_receive(dsp=df3ec000): UNDERRUN (or overrun), adjusting read pointer! (inst DSP_S1/C1)
Jun 13 15:58:17 [kernel] DSP_CANCEL_INIT called
Jun 13 15:58:17 [kernel] bchdev: echo cancel state 0 (idle)
Jun 13 15:58:17 [kernel] Enabling EC
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking dsp DSP_S1/C1
                - Last output repeated twice -
Jun 13 15:58:17 [kernel] -----Current DSP
Jun 13 15:58:17 [kernel] * DSP_S4/C1 echo=0 txmix=0
Jun 13 15:58:17 [kernel] * DSP_S1/C1 echo=0 txmix=0 *this*
Jun 13 15:58:17 [kernel] -----Current Conf:
Jun 13 15:58:17 [kernel] -----end
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking dsp DSP_S4/C1
Jun 13 15:58:17 [kernel] -----Current DSP
Jun 13 15:58:17 [kernel] * DSP_S4/C1 echo=0 txmix=0 *this*
Jun 13 15:58:17 [kernel] * DSP_S1/C1 echo=0 txmix=0
Jun 13 15:58:17 [kernel] -----Current Conf:
Jun 13 15:58:17 [kernel] -----end
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking dsp DSP_S4/C1
Jun 13 15:58:17 [kernel] searching conference 16
Jun 13 15:58:17 [kernel] conference doesn't exist yet, creating.
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking conference 16
Jun 13 15:58:17 [kernel] dsp_cmx_hardware conf 16 cannot form a HW conference, because dsp is alone
Jun 13 15:58:17 [kernel] -----Current DSP
Jun 13 15:58:17 [kernel] * DSP_S4/C1 echo=0 txmix=0 (Conf 16) *this*
Jun 13 15:58:17 [kernel] * DSP_S1/C1 echo=0 txmix=0
Jun 13 15:58:17 [kernel] -----Current Conf:
Jun 13 15:58:17 [kernel] * Conf 16 (c54c7920)
Jun 13 15:58:17 [kernel]   - member = DSP_S4/C1 (slot_tx -1, bank_tx -1, slot_rx -1, bank_rx -1 hfc_conf -1) *this*
Jun 13 15:58:17 [kernel] -----end
Jun 13 15:58:17 [kernel] DSP_CANCEL_INIT called
Jun 13 15:58:17 [kernel] Disabling EC
Jun 13 15:58:17 [kernel] bchdev: echo cancel state 0 (idle)
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking dsp DSP_S1/C1
                - Last output repeated twice -
Jun 13 15:58:17 [kernel] searching conference 16
Jun 13 15:58:17 [kernel] dsp_cmx_hardware checking conference 16
Jun 13 15:58:17 [kernel] dsp_cmx_hardware adding DSP_S4/C1 & DSP_S1/C1 to new PCM slot 0 (TX) 1 (RX) on same chip or one bank PCM, because both members have not crossed slots
Jun 13 15:58:17 [kernel] -----Current DSP
Jun 13 15:58:17 [kernel] * DSP_S4/C1 echo=0 txmix=0 (Conf 16)
Jun 13 15:58:17 [kernel] * DSP_S1/C1 echo=0 txmix=0 (Conf 16) *this*
Jun 13 15:58:17 [kernel] -----Current Conf:
Jun 13 15:58:17 [kernel] * Conf 16 (c54c7920)
Jun 13 15:58:17 [kernel]   - member = DSP_S4/C1 (slot_tx 0, bank_tx 0, slot_rx 1, bank_rx 0 hfc_conf -1)
Jun 13 15:58:17 [kernel]   - member = DSP_S1/C1 (slot_tx 1, bank_tx 0, slot_rx 0, bank_rx 0 hfc_conf -1) *this*
Jun 13 15:58:17 [kernel] -----end
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking conference 16
Jun 13 15:58:22 [kernel] dsp_cmx_hardware dsp DSP_S4/C1 & DSP_S1/C1 stay joined on PCM slot 0 (TX) 1 (RX) on same chip or one bank PCM)
Jun 13 15:58:22 [kernel] removing us from conference 16
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking dsp DSP_S1/C1
Jun 13 15:58:22 [kernel] dsp_cmx_hardware removing DSP_S1/C1 from PCM slot 1 (TX) 0 (RX) because dsp is split (no echo)
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking conference 16
Jun 13 15:58:22 [kernel] dsp_cmx_hardware conf 16 cannot form a HW conference, because dsp is alone
Jun 13 15:58:22 [kernel] dsp_cmx_hardware removing DSP_S4/C1 from PCM slot 0 (TX) 1 (RX) because dsp is split (no echo)
Jun 13 15:58:22 [kernel] -----Current DSP
Jun 13 15:58:22 [kernel] * DSP_S4/C1 echo=0 txmix=0 (Conf 16)
Jun 13 15:58:22 [kernel] * DSP_S1/C1 echo=0 txmix=0 *this*
Jun 13 15:58:22 [kernel] -----Current Conf:
Jun 13 15:58:22 [kernel] * Conf 16 (c54c7920)
Jun 13 15:58:22 [kernel]   - member = DSP_S4/C1 (slot_tx -1, bank_tx -1, slot_rx -1, bank_rx -1 hfc_conf -1)
Jun 13 15:58:22 [kernel] -----end
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking dsp DSP_S1/C1
Jun 13 15:58:22 [kernel] cmx_receive(dsp=df3d9000): UNDERRUN (or overrun), adjusting read pointer! (inst DSP_S4/C1)
Jun 13 15:58:22 [kernel] cmx_receive(dsp=df3d9000): UNDERRUN (or overrun), adjusting read pointer! (inst DSP_S4/C1)
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking conference 16
Jun 13 15:58:22 [kernel] dsp_cmx_hardware conf 16 cannot form a HW conference, because dsp is alone
Jun 13 15:58:22 [kernel] removing us from conference 16
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking dsp DSP_S4/C1
Jun 13 15:58:22 [kernel] conference is empty, so we remove it.
Jun 13 15:58:22 [kernel] -----Current DSP
Jun 13 15:58:22 [kernel] * DSP_S4/C1 echo=0 txmix=0 *this*
Jun 13 15:58:22 [kernel] -----Current Conf:
Jun 13 15:58:22 [kernel] -----end
Jun 13 15:58:22 [kernel] dsp_cmx_hardware checking dsp DSP_S4/C1

Gruß
Boesl

crich · 15 Jun 2006

Hier kann man sehen dass hardware bridging gemacht wird und zwar auf Konferenznummer 16:

[kernel] -----Current Conf:
Jun 13 15:58:17 [kernel] * Conf 16 (c54c7920)
Jun 13 15:58:17 [kernel] - member = DSP_S4/C1 (slot_tx 0, bank_tx 0, slot_rx 1, bank_rx 0 hfc_conf -1)
Jun 13 15:58:17 [kernel] - member = DSP_S1/C1 (slot_tx 1, bank_tx 0, slot_rx 0, bank_rx 0 hfc_conf -1) *this*
Jun 13 15:58:17 [kernel] -----end

dieselbe nummer kannst du im chan_misdn debug sehen wenn du dort einen level 4 angibst, und zwar steht dort dann etwas wir "bridging conference id=16" oder so ..

jedenfalls siehst du dass die slot und bank werte >= 0 sind und damit in hw gemacht werden.

q

Boesl · 18 Jun 2006

Danke,
dann ist das jetzt ja gelöst.

Vielen Danke und Gruß
Boesl

Bei bridging stürzt der komplette Rechner ab

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Mitglied

Neuer User

Mitglied

Neuer User

Neuer User

Mitglied

Neuer User

Mitglied

Neuer User

Statistik des Forums