zaphfc Warnungen ernst nehmen?

[divB]

Hallo,

Mein syslog ist voll von Meldungen dieser Art:

Sep  9 23:37:41 asterisk kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6207, z2=6200, wanted 8 got 7), probably a buffer overrun.
Sep  9 23:37:41 asterisk kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6207, z2=6200, wanted 8 got 7), probably a buffer overrun.
Sep  9 23:43:14 asterisk kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=7112, z2=7105, wanted 8 got 7), probably a buffer overrun.

Das gleiche hab ich auch schon mit underrun gesehen.

Ich hab nur eine AVM Fritz! und eine HFC Karte als S0 Bus drinnen. Also kein Flortz-Patch (da nicht nötig).

Prinzipiell scheint das Telephonieren am S0 Bus zu funktionieren, es konnte aber noch nicht ausgiebiger getestet werden.

Die Meldungen kommen auch massig wenn der NTBA gar nicht angesteckt ist!

Hab leider noch nix finden können was die Meldungen wirklich heissen.

Hab nur was gelesen dass man der Karte nen eigenen IRQ geben soll.

$ cat /proc/interrupts
           CPU0
  0:    2126716    IO-APIC-edge  timer
  1:        280    IO-APIC-edge  i8042
 14:      76410    IO-APIC-edge  ide0
 15:         60    IO-APIC-edge  ide1
169:     297750   IO-APIC-level  acpi, eth0
177:   67965137   IO-APIC-level  zaphfc, ehci_hcd:usb1
185:          0   IO-APIC-level  uhci_hcd:usb2
193:    2120993   IO-APIC-level  uhci_hcd:usb3, fcpci
NMI:          0
LOC:    2126763
ERR:          0
MIS:          0

Ok, die Karte scheint den Interrupt mit dem USB-Controller zu teilen. Andrerseits ist APIC aktiv.
Wie kann ich das umsortieren (dass aber trotzdem noch jede Hardware ihren IRQ bekommt)?

Soll ich sie Ernst nehmen? (das will ich!)
Was bedeuten sie?
Wie bekomme ich sie weg?

Vielen Dank an alle Ideen

 

[kombjuder]

Soll ich sie Ernst nehmen? (das will ich!)

Wenn es vereinzelt auftritt nicht, wenn gehäuft dann ja, die Sprachqualität wird schlecht.

Was bedeuten sie?

Das (Sprach-)Pakete verloren gingen, da diese nicht schnell genug abgeholt wurden. Die hast schlicht Pufferüberläufe.

Wie bekomme ich sie weg?

Indem du dein Rechnerbios davon überzeugst, deiner Hfc einen eigenen IRQ zuzuweisen, freie gibt es ja genug.

Andere Möglichkeit wäre, dein Rechner ist überlastet, aber eher unwarscheinlich.

Wenn alles nichts hilft, doch den Florz probieren, der hat generell ein besseres irq-Handling.

 

[divB]

Hallo!

Vielen Dank für die Antwort!

Naja, gehäuft kommt sie nicht vor. Ich verwende halt logcheck und da ist sind bei jeder zweiten Mail ca 5 Zeilen drinnen.

Das kranke ist aber, dass die Meldungen auch kommen (!) wenn gar kein NTBA angeschlossen ist! D.h. es sollte gar nix übertragen werden!

florz-Patch hatte ich schon versucht --> keine Besserung (wieso wird der eigentlich nicht offiziell eingebaut wenn er eh nur eine Verbesserung darstellt?)

Gut, aber das mit IRQ könnt ich versuchen.
IMHO sollte das ja ACPI machen, imho, aber trotzdem, wie weise ich einer bestimmten Karte einen eigenen IRQ zu?
Geht das nur über das BIOS?
Ich dachte, BIOS Einstellungen seien nur für den Boot relevant, da sich Linux sowieso über das BIOS hinwegsetzt?

 

[jeffjohnson]

Ich hab das gleiche Problem.
Meine HFCpci karte hat bereits einen eigenen IRQ zur Verfügung der nur von der ISDN Karte benutzt wird.
Ich ahb auch schon florz patch ausprobiert die Fehlermeldung tritt trotzdem noch auf...

Das es an der Rechnerleistung liegt ist eher unwahrscheinlich, ist ein Dual P4 mit >2,4GHZ und 1GB RAM.
Wodran könnte es noch liegen? Ich hab auch schon verschiedene Asterisk+bristuff Versionen ausprobiert...

 

[divB]

Ich habs aufgegeben.
Wenn eine Karte 8000 (!!) Interrupts pro Sekunde feuert dann gibts nur *würg*. Aber ok, es ist ja auch Billig-Hardware.
Da wird es nicht anders gehn.

Ich hab auch ein bisschen Sourcecode gelesen und im Internet gesucht, es gibt die Möglichkeit mit Realtime. Dazu muss man aber den Kernel patchen und ein MEGA-Paket installieren. Doch das größere Problem ist dann, dass der Takt nicht mehr synchron ist.
Der Interrupt wird zwar nur mehr im 1kHz Takt aufgerufen aber dafür berichten Leute von Echos und extrem verminderter Sprachqualität wegen der fehlenden Synchronisierung.

Meine Hardware kann auch nicht zu schmal sein, 1.7Ghz P4, 512MB RAM, hab der Karte auch schon nen eigenen IRQ zugewiesen.

Trotzdem scheint es, als ob die Meldungen kommen, wenn der PC ausgelastet is, z.B. wenn ein bzip rennt und die CPU-Resourcen frisst.

Im Regelfall ists normal.

Solange es funktioniert, finde dich damit ab. Das ist eben der Nachteil wenn man so billige Hardware einsetzt. Mit den teuren Karten von Digium & Co wirds diese Probleme eben nicht geben.

 

[jeffjohnson]

Oder man setzt die misdn Treiber ein...
Damit rennt eine Installation der HFCpci ohne Probleme

 

[divB]

mISDN ist aber noch nicht wirklich stable genug oder?

Hmm, aber: Kann mit mISDN die HFC Karte im NT Modus betrieben werden? Das läuft dann ja wenn gar nicht über BRIstuff oder?

Hast du das am Laufen? Funzt das gut?

 

[jeffjohnson]

Läuft Stabil als VoIP Gateway für Auslandsgespräche bei uns, ich hatte noch keine Probleme mit den misdn Treibern.
Die Karte kann im NT wie natürlich auch im TE Modus betrieben werden. Bei uns läuft sie im TE Modus, NT Modus hab ich nocht getestet

 

[divB]

Ok, einen Versuch wärs vielleicht wirklich mal wert.

Aber mISDN/chan_misdn gilt ja als stable oder?

Ich hab immer so meine Bedenken mit nicht nicht ausgereifter Software
wenn ichs nicht gerade als Versuchssysteme einsetze.

 

[frank.g]

Moin zusammen!

Bei mir hat geholfen, alles was mit Power Management zu tun hat, abzuschalten:
- BIOS: Power Management DISABLE
- Kernel: keine APM-Unterstützung konfigurieren oder apm=off in die Boot-Zeile einfügen.

Der Grund, zumindest bei mir: Bei aktivierten APM fragt der Kernel in regelmäßigen Abständen das APM-BIOS (durch Call-Aufruf) ab. Während der Aufrufe sind in der Default-Einstellung alle Interrupts gesperrt. Dauert der Aufruf länger als 125us, gehen von den Interrupts der HFC-Karte (ein Interrupt pro 125us) welche verloren, da die Hardware-Interrupt-Anforderung nach ebendieser Zeit durch die nächste überschrieben wird.

Das ganze scheint von der Implementierung des APM-BIOS, d.h. vom Motherboard, abzuhängen (es ist bei mir ein ASUS P4B533, das ansonsten einwandfrei läuft).
Dieses Phänomen betrifft übrigens auch andere Karten, nur dort fällt es kaum auf, weil die Interrupts wesentlich seltener auftreten.

Grüße,
Frank

 

[divB]

Juhuuu!
Ohne es probiert zu haben: Ich hab ebenfalls ein P4B!

Ich glaub dass ich im BIOS alles in Bezug auf Power Management abgeschaltet hab aber mit apm=off werd ichs auch einmal probieren und dann meine Erfahrungen hier reinstellen.

Aber dazu noch eine Frage:
Braucht man APM überhaupt noch wenn man ACPI hat? ACPI löst ja APM sowieso ab oder?
Gibts diese "Polling"-Abfrage nur bei APM und bei ACPI nicht?

Schaltet sich der Rechner trotzdem automatisch ab, auch wenn man kein APM hat?

Im Endeffekt wär mir das eh alles egal, ist ja eh a Server

 

[divB]

SCHEI**! Scheints nicht zu sein :-(

$ cat /proc/cmdline
root=/dev/hda6 apm=off
$ uname -r
2.6.17.11.20060805
$ tail /var/log/syslog
[...]
Oct  8 23:49:07 linux kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6911, z2=6904, wanted 8 got 7), probably a buffer overrun.
Oct  8 23:49:07 linux kernel: zaphfc: bchan rx fifo not enough bytes to receive! (z1=6911, z2=6904, wanted 8 got 7), probably a buffer overrun.
Oct  9 00:01:49 linux kernel: zaphfc: dropped audio (z1=700, z2=682, wanted 8 got 18, dropped 10).

 

[frank.g]

Moin,

in Anknüpfung an Erfahrung mit Datenerfassungskarten unter Linux habe ich dem zaphfc-Teiber einen kleinen Patch verpasst. Dieser verleiht ihm hohe Toleranz von verlorenen Interrupts, indem er die Datenbytes nachzählt und die versäumte Arbeit nachholt. Läuft bei mir (Kernel 2.4.33, bristuff-0.2.0rc8s) einwandfrei, keine Meldungen mehr. Auch das gelegentliche "Klacken" ist verschwunden. Da der zaphfc-Treiber auch bei neuerem bristuff derselbe ist, sollte er auch da laufen. Ich kann sogar das APM wieder einschalten, ohne dass man den Unterschied hört, allerdings kommen dann wieder Meldungen ca. 1 mal am Tag.

Siehe http://home.arcor.de/frank.gockel/software/zaphfc/ (bitte Doku in *.txt lesen, Seite ist gerade im Entstehen begriffen. Und der Code ist möglicherweise noch weiter verbesserungswürdig.)

Mit ACPI habe ich keine Erfahrung. Das Abschalten per APM geht auch, wenn man APM als Modul compiliert, aber nicht lädt. Nur kurz vor den Befehlen "halt" oder "poweroff" in den Shutdown-Scripten muss dann ein "modprobe apm" ;-)

Grüße,
Frank

 

[divB]

Vielen Dank für deine Antwort und den Patch!

Ich habe ihn gestern installiert und ausprobiert, es erscheinen gleiche viele Meldungen wie eh und je :-(
Ich glaub es is hoffnungslos

mfg,
divB

 

[frank.g]

Hallo divB(?),

habe den Treiber nochmals angefasst, da bei mir nach ein paar Wochen Dauerbetrieb doch zwei Fehlerchen auftraten. Der Teufel steckt im Detail
Vielleicht gibst du der HFC-Karte noch eine Chance...

Der florz-Patch funktioniert bei mir übrigens gar nicht, er liefert nur syslog-Meldungen über Pufferüberläufe und der Wählton klingt wie Oskars scheppernde Mülltonne. Telefonieren geht überhaupt nicht.

Habe inzwischen das Mainboard im Verdacht, dass es Interrupts frisst (es muss eine sehr hungrige Spezies sein...). Okay, es ist vollgestopft mit vielen Karten, aber die HFC-Karte hat einen Interrupt für sich alleine. Es funktioniert bei mir nur mit dem angepassten, IRQ-Loss-toleranten zaphfc-Treiber, und zwar sehr stabil

Hat sonst noch jemand diese Konfiguration und kann über Erfahrungen berichten?

Viele Grüße,
Frank

-----------------------------
System: Slackware-10.2
Kernel: 2.4.33
BRIstuff 0.2.0-RCs mit asterisk 1.0.11.1 und obigem, angepassten zaphfc-Treiber
HFC-PCI-Karte im NT-Modus (mit eigenem Interrupt)
AVM-Fritz-PCI-Karte im TE-Modus mit CAPI-Treiber von AVM und chan-capi
Mainboard: ASUS P4B

 

[divB]

Hallo Frank!

Ja, divB, eigentlich divB=0 (das =0 spar ich mir wegen der Äquivalenz ;-) ). --> Ist ein Teil der maxwellschen Gleichungen

Also ich will jetzt nichts verschreien, aber seit meinem Neustart (lt. Uptime seit genau 1 Tag, 5:40) hatte ich mit deinem Patch auf einmal keine einzige Meldung mehr!! Wollt mich schon melden und das berichten.

Was ich daran nicht ganz verstehe: Ich hab während des Betriebs deinen Patch applied, den Treiber compiliert, rmmod gemacht, deine Version drüberkopiert und modprobe gemacht. Keine Änderung (wie in meinem letzten Post geschrieben).
Jetzt, nach einem Neustart, auf einmal keine Meldungen mehr.

Was ich schade finde ist, dass ich immer genau die Hardware hab die Probleme bereitet (jetzt ist es das P4B :-( )

Zwei Fragen noch:
a) Was sind die zwei Fehlerchen die im Detail stecken? Haben die was mit deinem Patch zu tun? Weil bis jetzt ist mir (deswegen auch der o.g. Neustart) das Linux komplett eingefroren, sodass weder Monitor noch Tastatur mehr ging. Es muss an Asterisk (entweder fcpci oder zaphfc) liegen, da der Rechner mitten in einem Telephongespräch abgestürzt ist und der letzte Eintrag vom CAPI Treiber stammt, der diesen Anruf angenommen hat.
Alles in allem nicht beruhigend, ich hoffe nicht, dass das ein Normalfall wird und an deinem Patch liegt.
Falls doch (und das eines der Problemchen sein könnte) lass' es mich bitte wissen damit ich Vorkehrungen treffen kann

b) Meinst du mit "IRQ-Loss-toleranten zaphfc-Treiber" nun deinen Patch?

mfg,
divB

 

[stefanwillmerot]

Hat sonst noch jemand diese Konfiguration und kann über Erfahrungen berichten?

Hallo Frank,

ich habe eine HFC-S in einem älteren P2-333, dürfte ein Asusboard sein. Mit Florz-Patch hatte ich permanent Fehlermeldungen (overrun/underrun) im Log, mit Deiner Version hingegen läuft nun alles perfekt. Ein dreifaches Hip-Hip-Hurra!

Stefan

 

[frank.g]

Hallo divB (ah, E-Techniker, tach Kollege)!

Zu a)
Da muss beim "rmmod" etwas schiefgegangen sein, jedenfalls war dann nicht der neue Treiber geladen. Das kannst du anhand der ersten Meldungen im syslog prüfen, denn der gepatchte Treiber meldet sich mit einer Versionsnummer 1.0.3, während der Original-Treiber (dem ich per Definition die Nummer 1.0.0 gebe) gar keine Versionsnummer ausspuckt. Die Fehlerchen, die ich meine, stehen in der Doku zum Patch, würden aber keinesfalls zum völligen Systemabsturz führen. Der Treiber ist bei mir seit Wochen im Dauertest, auf einem Recher, der permanent durchläuft, weil er u.a. auch noch die Heizung regelt

Zu b)
Mit den "IRQ-Loss-toleranten, angepassten Treiber" meine ich natürlich meinen Patch.

Grüße,
Frank

 

[divB]

Hallo!

Mit der Zeit glaub ichs! Ich hab seither keine Meldungen mehr erhalten, das System scheint stabil zu laufen und Gesprächsqualität kein Problem zu sein. Das ganze jetzt seit über einer Woche!

Danke für den Patch, du hast gute Arbeit geleistet!

Was noch fehlt ist ein "offizieller" Name ;-), Heimseite gibt es schon und dann bei voip-info.org etc ein Link dazu
Damit anderen Leuten auch geholfen werden kann!

mfg,
divB