channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)

[bubble]

Hallo,

gibt zu folgendem schon was Neues?

channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)

bei den Jungs von mISDN steht dazu schon was im Bugtracking, es tut sich aber nichts.

Bei mir tritt das immer nach ner Weile auf, mein gegenüber hört mich dann noch, nur bei mir ists ruhig.

Bubble

 

[crich]

Wie meinst du dein gegenüber? Hast du ein SIP Phone und der ein ISDN Phone ? Kannst du das etwas genauer beschreiben bitte.

 

[sterkel]

channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)

Also wir haben das auch haufenweise im Logfile, Aussetzer konnten wir aber nicht feststellen bisher.
Unsere Konfig: Telekom ISDN <--->HFC-*-HFC<--->Alcatel

Bisher wird auch nur reines isdn-LCR gemacht und das läuft seit 2 Wochen eigentlich stabil.

 

[crich]

Die Meldung kommt bei jedem, immer mal ein paar von den Dingern pro call .. macht aber eben tatsächlich keine Schwierigkeiten "normalerweise".

 

[bubble]

Ich bekomme nicht nur nen Paar sondern hunterte. Erst komme so zwei drei, man telefoniert weiter und nach ca. 10 min manchmal auch früher rasseln die im Log nur so durch und ich höre mein Gegenüber nicht mehr. Bei
alten chan_misdn und mISDN Versionen hatte ich das Problem nicht. Ist das evtl. nur beim HFC-S Usb so?

Bubble

 

[lo4dro]

Hallo.

Ich hab zwei HFC-PCI Karten und im log steht so was auch ständig.
Wirk sich allerdings nicht negative aus.

 

[bubble]

Sind die Fehler bei mISDN oder chan_misdn zu suchen?

Bubble

 

[crich]

Ich meine das ist ein hfcpci Treiber Problem. Die Meldungen tauchen auch beim hfcmulti auf allerdings immer nur kleckerweise und wirken damit auch nicht störend.

Ich würde nochmals mehr Druch im Mantis Bug auf der i4l Seite dazu machen, berichte doch dein Problem dort nochmal etwas genauer.

 

[bubble]

Bei i4l tut sich irgendwie garnichts. ;(
Aber werde mal noch nen bissel was reinschreiben.

Bubble

 

[HobbyStern]

Ich darf den Thread nochmals aufwärmen...

Kann über selbiges Problem klagen - allerdings erst seit dem Update mISDN 0.3.0 RC25 auf 0.3.0 stable.


Was mir aufgefallen nach dem Installationsneustart ist folgendes :

Apr  1 22:23:28 Asterisk kernel: usbcore: registered new driver wcusb

Der Vorteil am Update auf die stable - "diese" Meldungen fallen endlich weg :

Apr 20 17:12:09 Asterisk kernel: ECHOCAN: TXBUF Underrun len:0 newlen:128
Apr 20 17:16:06 Asterisk kernel: dev_manager prim f1780 not handled 
Apr 20 17:16:06 Asterisk kernel: unregister_instance: no layer found
Apr 20 17:16:20 Asterisk kernel: data[0]: 64 data[1]: 0, len :8          
Apr 20 17:16:20 Asterisk kernel: DSP_CANCEL_INIT called            
Apr 20 17:16:20 Asterisk kernel: bchdev: echo cancel state 0 (idle) 
Apr 20 17:16:20 Asterisk kernel: Enabling EC

Der Nachteil - nun darf ich mich hier im Club anschliessen :

Apr 21 06:25:44 Asterisk kernel: Warning: kfree_skb on hard IRQ e0b34164 
Apr 21 06:26:19 Asterisk last message repeated 10 times                 
Apr 21 06:27:24 Asterisk last message repeated 20 times                  

und

Apr 24 10:42:28 Asterisk kernel: channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)

usw usf

Ich habe keine Störungen in den Gesprächen ausfindig machen können.

Diese Thematik wurde in einem Kernel-Forum schon einmal aufgegriffen (hatte ich mal gelesen) - das ausschalten der USB Kompatibilität brachte Abhilfe, daher schliesse ich mich der Frage von bubble an :

Ist das evtl. nur beim HFC-S Usb so?

Any Idea?

 

[crich]

Es sieht fast danach aus als ob es nur den hfc usb betrifft. Habt ihr schonmal in die i4l mailingliste deswegen gerufen ?

 

[HobbyStern]

Gerade geschehen, die Fehlermeldungen machen wirklich kein Theather in Gesprächen, füllen aber Seiten der Logfiles.

Mal sehen was rauskommt..

Grüsse, Stefan

 

[HobbyStern]

Lt der i4l Mailingliste ist eine Kombination mit USB weniger denkbar.

Die IRQ Errormeldung ist Kernel-Versionsbedingt "mein Problem".

Die Channel Senddata ist ein bedeutungsloser Output - wird ggf. mal herausgenommen.

QUIT

 

[HobbyStern]

@crich

Eine Sache habe ich auf dem Herzen.

ich bekomme ja abwegig von dem channel_senddata auch einen IRQ Error ausgespuckt.

Lt i4l Liste ist die memleak-debug funktion in meinem misdn kernel config aktiv.

Da ich bisher das automakefile genutzt habe war ich etwas stutzig, wie soll ich vorgehen um dieses nun sauber zu deaktivieren ?


Danke für Deinen Support und Beste Grüße,

Stefan

 

[medic]

*seufzt*
Ich leide unter dem gleichen Problem

ein paar Fehlermeldungen der Art "channel_senddata: next_skb exist ERROR (skb->len=64 next_skb->len=64)" habe ich auch immer wieder, ich glaube sie vor allem dann zu haben, wenn es knackt. Aber ich kann damit leben.

Das Problem ist, daß es einen Punkt gibt, in dem das Gespräch fuer mich ganz abreisst, und dann laufen diese Fehlermeldungen nur so in mein Logfile.

Es ist mit den neusten Versionen zwar so, dass er mir nicht mehr den gesamten internen S0-Bus damit killt, aber toll ist der ungeplante Verbindungsabbruch nach unbestimmter Zeit auch nicht (früher waren es regelmäßig um die 5 Minuten, jetzt sind es zwischen 2 und 16)

Kann da jemand helfen ? .. ich bin echt ratlos.

Vor allem da es das einzige Setup ist, was bisher einigermaßen gut funktioniert.

Danke
medic

 

[lo4dro]

@HobbyStern

Ich vermute diese "memleak-debug" Funktion ist einen Kernel funktion.
Damit du das abschalten kannst, must du den Kernel neu Kompilieren.

 

[HobbyStern]

@lo4dro

Ist im Kernel, richtig, jedoch übernimmt diese Schritte ja das automatische installfile von beronet und da die memleak-konfig ein teil vom misdn konfigurierten kernel-teil ist ......