channel buffer underrun / overflow problem

htims · 12 Aug 2005

Hallo,

ich setzte bristuff in Version RC8n mit dem neuesten florz patch und kernel 2.6.12.2 ein.

Asterisk in Version 1.0.9 (von bristuff installiert).

Die beiden Karten haben verschiedene Interrupts:

Code:

cat /proc/interrupts  | grep zaphfc
  9: 1290208928          XT-PIC  zaphfc
 11:  113171112          XT-PIC  zaphfc

Nach einer gewissen Zeit (es waren jetzt ein paar mal ca. 2 Stunden) bekomme ich ins kern.log folgendes geschrieben:

Code:

kernel: zaphfc[1]: b channel buffer overflow: 37, 37
kernel: zaphfc[0]: b channel buffer overflow: 37, 37
kernel: zaphfc[1]: b channel buffer underrun: 1, 1
kernel: zaphfc[0]: b channel buffer underrun: 1, 1
kernel: zaphfc[1]: b channel buffer overflow: 36, 36
kernel: zaphfc[0]: b channel buffer overflow: 36, 36
kernel: zaphfc[1]: b channel buffer underrun: 1, 1
kernel: zaphfc[0]: b channel buffer underrun: 1, 1

Sobald diese Meldungen auftauchen steigt der Load des Systems, da klogd und syslogd einiges zutun bekommen.

Die Probleme ließen sich bis jetzt immer durchs stoppen von Asterisk, und dem neuladen von zaptel und zaphfc beheben, nur kann dies doch wohl keine Dauerlösung sein!

Irgentwo laß ich, dass man die Festplatten in den umask irq Modus setzten soll um diese Probleme zu verhindern (hdparm -u1 /dev/hd..). Dies half jedoch nicht.

Vielen Dank vorab!

kombjuder · 12 Aug 2005

htims schrieb:
ich setzte bristuff in Version RC8n mit dem neuesten florz patch und kernel 2.6.12.2 ein.

Der florz-Patch passt aber nicht zu der Bristuff-Version. Versuche mal die RC8j mit dem Patch, ob dann immer noch die Fehler auftreten.

Wenn nicht, frag mal google zu Asterisk und Kernel 2.6.11 und 12

htims · 12 Aug 2005

ok mache ich.

der Patch von florz hat sich jedoch ohne weiteres bei rc8n einfügen lassen.-- eigentlich immer ein gutes zeichen --

ich sehe gerade, dass auf der seite des florz patches von buffer under and overruns im zusammenspiel mit rtai gesprochen wird, weswegen der patch dies komplett entfernt. -- mal hoffen das dies bei der "j" version besser funktioniert.

kombjuder · 12 Aug 2005

htims schrieb:
-- eigentlich immer ein gutes zeichen --

Zeichen trügen gelegentlich. Wenn die fehlerhafte Funktion beim Start nicht angesprochen wird, sondern nur z.B. beim Wählen taucht auch dort erst das Problem auf.

htims · 12 Aug 2005

habs probiert -- leider immer noch das selbe problem. der fehler tritt jetzt nur schneller auf (und unabhängig davon ob telefoniert wird oder nicht).

Der Fehler war noch nie vom Telefonieren abhängig.

Gerade eben wurde der Server nach ca. 10 Minuten komplett unerreichbar.

gibt es noch weitere tipps?

Karl23 · 15 Aug 2005

Was für eine CPU ist das?

XT-Pic ? altes MB?

Zwei HFC Karten erzeugen eine sehr hohe IRQ last.

procinfo -d -n1 zeigt pro karte int 8000/sec.

mit florz patch kann dies vermieden werden, wenn die Hardware
Clock verbindung gemäß der Beschreibung auf der florz Seite erstellt
und dies dem Treiber beim laden mitgeteilt wird. (Master/Slave)

Es wird dann nur die IRQ wie bei einer Karte erzeugt.

htims · 15 Aug 2005

es ist ein p2 400, das board ist entsprechend alt.

ja, xt-pic lese ich unter /proc/interrupts

beim florz patch muss man nicht mal irgentwas angeben (jedenfalls bei 2 karten) - der patch setzt automatisch eine als slave und eine als master - afaik.

dies passiert auch.

Karl23 · 15 Aug 2005

Diese Hardware ist mit zwei HFC karten überfordert.

Was zeigt procinfo -d -n1?

Wenn man die Hardware ergänzung macht ist nur boch eine
Karte die Interrupt source das reduziert die IRQ last auf die Hälfte.
Wenn man den Hardware Mod nicht macht nützt der florz patch nicht sehr viel.

gruß

kombjuder · 15 Aug 2005

Karl23 schrieb:
Wenn man den Hardware Mod nicht macht nützt der florz patch nicht sehr viel.

Das halte ich aber für ein ziemliches Gerücht!
Ich habe hier 3 HFC drin, davon produziert nur eine fast exakt 8000 IRQ, die die ich mit timer_card= benannt habe. Die beiden anderen bringen gelegentlich einen IRQ hervor.

htims · 17 Aug 2005

bei mir macht eine karte mit florz patch auch ca. 8000 interrupts / sekunde. die andere wie auch bei kombjuder gelegentlich einen.

was meinst du mit "hardware mod"?

gibt es irgentwelche erfahrungen mit slot 1 (pentium 2) mainboards auf denen 2 oder mehrer hfc-s karten gut laufen?

kombjuder · 17 Aug 2005

htims schrieb:
was meinst du mit "hardware mod"?

Guckst du hier: http://zaphfc.florz.dyndns.org.

gibt es irgentwelche erfahrungen mit slot 1 (pentium 2) mainboards auf denen 2 oder mehrer hfc-s karten gut laufen?

HP Vectra vli8 mit einer Fritz und 1 HFC. (Die zweite HFC ist noch nicht da.)
Eigentlich problemlos, du musst dir nur freie irq verschaffen, also lpt und seriell ausschalten wenn du sie auf dem Rechner nicht brauchst.

htims · 17 Aug 2005

hm.. ja habe ich bei mir schon alles gemacht. ich vermute mal das der alte via-chipsatz irgentwie probleme macht....

hm der hardware mod kommt für mich nicht in frage.

malibu · 18 Aug 2005

Ist es wirklich möglich, dass eine einzelne HFC-Karte in einem älteren System (Epox 8kta mit VIA-Chipsatz - mit XT-PIC - Duron 750 ) überhaupt nicht funktioniert?
Sobald irgend eine andere Anwendung im Rechner ebenfalls Interrupts erzeugt verabschiedet sich das gesamte System mit jeder Menge Meldungen der Art:

zaphfc[0]: b channel buffer underrun

Meine bisherigen Versuche waren

- Durchtauschen der PCI Karten im System
- Ein eigener IRQ für die Karte
- der Florz' Patch für bristuff-0.2.0-RC8n
- Verschiedene Kernel-Versionen von (2.6.8 - 2.6.11)
- hdparm -u1

Gibt es noch irgendwelche Lösangsansätze, abgesehen vom Erwerb eines neuen Mainboards? Wo liegt denn genau das Problem mit dem XT-PIC??
Kann man das IRQ-Handling evtl. umstellen?

Mit den besten Grüßen
Christoph

htims · 18 Aug 2005

du kannst versuchen, den kernel mit "lapic" als kernel boot-option zum nutzen von apic zu zwingen - bei mir klappt das aber auch nicht.

bei mir läuft es jetzt seit 9 stunden stabil... und das ist für mich neuer rekord.
zu den sachen die du genannt hast habe ich folgendes gemacht:
1. zaphfc mit der option jitterbuffer=8 geladen (zzgl. zu modes=1)
2. einen kernel gebaut der kein preemptible kernel ist.

erst hatte ich nur den kernel gebaut und es lief schon rund. das mit dem jitterbuffer hab ich nurnoch vorsichtshalber gemacht. ( spiel mal selber mit den werten für den jitterbuffer... je kleiner du ihn machst und das system stabil läuft um so besser)

ich bin im moment auf der suche nach einem mainboard das apic unterstützt, um noch weniger probleme zu haben und evtl auf den jitterbuffer verzichten zu können -- erstmal hoffen das es so weiter läuft.

malibu · 20 Aug 2005

Die jitterbuffer Option zögert den Absturz lange heraus. Aber von stabil kann man leider noch nicht sprechen.

APIC laden hat mittlerweile funktioniert - hat aber keinen merkbaren Unterschied zur Folge.

Code:

Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to ffffd000 (fee00000)
PCI: Disabling Via external APIC routing

Leider sieht es ganz danach aus, als ob der Debian-Stadard-Kernel (2.6.11-1-k7), den ich einsetze bereits ein nicht-preemptible-kernel ist. Macht es Sinn auch einen Preemptible Kernel auszuprobieren, oder ist das ohnehin Zwecklos?

Gibt es eine Möglichkeit den Load des Systems, der durch die zahlreichen
"zaphfc[0]: b channel buffer overflow:" Nachrichten entsteht zu verringern, denn mein System wird momentan dadurch unerreichbar, somit bin ich ständig gezwungen den Resetknopf zu benutzen..

htims · 20 Aug 2005

wenn du das logging (syslogd, klogd) deaktivierst sollen die logging bedingten abstürtze vermieden werden..

hm also bei mir gehts mit einem jitterbuffer von jetzt 10 und einem -nicht- preemtible kernel sehr gut. mir viel auf, dass die bufferoverflows und underruns zwar noch passieren, jedoch keine auswirkungen auf den betrieb haben, da sie sofort wieder aufhören!

malibu · 21 Aug 2005

Nachdem ich den Server auch noch zu anderen Zwecken einsetze kommt für mich das Abschalten des syslogd nicht in Frage. Deshalb habe ich die Log-Messages aus dem zaphfc Modul (zaphfc.c) auskommentiert:

Code:

// if(chtmp->initialized)
 printk(KERN_CRIT "zaphfc[%d]: b channel buffer underrun: %d, %d\n",hfctmp->cardno,chtmp->tx.c[0].filled,chtmp->tx.c[1].filled);

// if(chtmp->initialized)
   // printk(KERN_CRIT "zaphfc[%d]: b channel buffer overflow: %d, %d\n",hfctmp->cardno,chtmp->rx.c[0].filled,chtmp->rx.c[1].filled);

Nun scheint es bei mir jitterbuffer=1 und einem preemptible (?!) Kernel sehr stabil zu laufen.
Zuvor hatte ich es mit hohen jitterbuffer-Werten (>30) und einem nicht-preemptible Kernel versucht, was leider nicht zum Erfolg führte...

htims · 21 Aug 2005

hm... wenn es so stabil läuft dann frage ich mich warum diese meldung überhaupt ausgegeben wird.

florz fügt sie ja erst in seinem patch hinzu....

channel buffer underrun / overflow problem

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Neuer User

Neuer User

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Statistik des Forums