kernel: zaphfc: sync lost, pci performance too low...

[spoky]

Hallo,

Ich verwende bri-stuff.0.1.0-RC4a und den damit verknüpften Asteriskserver. Weiterhin habe ich zwei HFC ISDNKarten im Einsatz. Eine im NT-Mode, die andere im TE-Mode.
Nach kurzer Asterisklaufzeit erhielt ich folgendes im syslog:

kernel: zaphfc: sync lost, pci performance too low. you might have some cpu throtteling enabled.

Das ganze pustete nicht nur die logfiles megabyteweise auf, sondern erhöhte auch den Systemload auf mind. 1.2.
Meine Hardware ist ein Dual PIII mit 392MB RAM, der eigentlich nicht viel arbeit hat. kernel 2.6.7
Desweiteren stellte sich heraus, dass der uhci-hcd (Der usbtreiber halt) die reibungslose Asterisklaufzeit erheblich verkürzte. Allgemein formuliert könnte man vermuten, dass jeder irq intensive Treiber den zaphfc aus der bahn wirft.

Beginnt der zaphfc Treiber einmal mit dem kernellogging, so kommt er aus diesem "Teufelskreis" nicht mehr raus und erhöht, druch das logging den Systemload auf ca. 1.2.

Das deaktivieren des kernelloggings, des zaphfc-treibers hat für mich das Problem gelöst. Mein System läuft seitdem auch mit dem usbtreiber stabil und der systemload ist wieder normal. Das telefonieren funzzt auch einwandfrei.

Einziges Problem ist weiterhin noch, dass ich den zaphfc Treiber nicht unloaden kann. Das führt regelmäßig zu einem kernelfreeze.

Hat jemand ähnliche Erfahrungen gemacht bzw andere Lösungen gefunden? Leider ist mein C nicht gut genug, um das Problem elegant im Treiber zu fixen.

mfg spoky

 

[sion]

Hallo,

Ich verwende bri-stuff.0.1.0-RC4a und den damit verknüpften Asteriskserver. Weiterhin habe ich zwei HFC ISDNKarten im Einsatz. Eine im NT-Mode, die andere im TE-Mode.
Nach kurzer Asterisklaufzeit erhielt ich folgendes im syslog:

kernel: zaphfc: sync lost, pci performance too low. you might have some cpu throtteling enabled.

Das ganze pustete nicht nur die logfiles megabyteweise auf, sondern erhöhte auch den Systemload auf mind. 1.2.
Meine Hardware ist ein Dual PIII mit 392MB RAM, der eigentlich nicht viel arbeit hat. kernel 2.6.7
Desweiteren stellte sich heraus, dass der uhci-hcd (Der usbtreiber halt) die reibungslose Asterisklaufzeit erheblich verkürzte. Allgemein formuliert könnte man vermuten, dass jeder irq intensive Treiber den zaphfc aus der bahn wirft.

Beginnt der zaphfc Treiber einmal mit dem kernellogging, so kommt er aus diesem "Teufelskreis" nicht mehr raus und erhöht, druch das logging den Systemload auf ca. 1.2.

Das deaktivieren des kernelloggings, des zaphfc-treibers hat für mich das Problem gelöst. Mein System läuft seitdem auch mit dem usbtreiber stabil und der systemload ist wieder normal. Das telefonieren funzzt auch einwandfrei.

Einziges Problem ist weiterhin noch, dass ich den zaphfc Treiber nicht unloaden kann. Das führt regelmäßig zu einem kernelfreeze.

Hat jemand ähnliche Erfahrungen gemacht bzw andere Lösungen gefunden? Leider ist mein C nicht gut genug, um das Problem elegant im Treiber zu fixen.

mfg spoky

Die Probleme sind mir nicht ganz fremd, allerdings hatte ich noch nie das "pci performance too low" Problem.
Das Unload klappt nicht vernünftig, und in den letzten 5 Tagen hatte ich 2 Freezes. Seit dem ich die HFC-Karte eingebaut habe, hatte ich auch schon Probleme mit einer Festplatte (IRQ-Intensiv?, siehe unten), bei der im Betrieb der DMA-Modus abgeschaltet wurde.
Wie/Wo kann man denn das kernellogging ausschalten?

hier meine IDE-DMA-Fehlermeldung:

Sep 24 17:43:14 server kernel: hda: dma_timer_expiry: dma status == 0x61
Sep 24 17:43:24 server kernel: hda: DMA timeout error
Sep 24 17:43:24 server kernel: hda: dma timeout error: status=0xd0 { Busy }
Sep 24 17:43:24 server kernel:
Sep 24 17:43:24 server kernel: hda: DMA disabled
Sep 24 17:43:24 server kernel: hdb: DMA disabled
Sep 24 17:43:24 server kernel: ide0: reset: success

 

[spoky]

Hallo,

das loggin ist ganz einfach in der zaphfc.c auszukommentieren:
Zeile 640-643 sieht dann wie folg aus:

/*      if (s2 & hfc_M2_PMESEL) {
            // kaboom irq (bit 7)
            printk(KERN_CRIT "zaphfc: sync lost, pci performance too low. you mi
        } */

mfg spoky

 

[sion]

Dachte, es gibt einen Compilierschalter der alle Nachrichten ausschaltet; offensichtlich jedoch nicht.
Habe nochmal genauer nachgesehen, genau diese Meldung ist bei mir noch nicht aufgetreten, mein Treiber macht anderen Unsinn ;-)

 

[H_I_M]

Ich würde sagen es ist das selbe Problem wie bei PBX4linux die Karten sollten kein IRG-Sharing betreiben. Soll heißen jede ISDN-Karte sollte einen eigenen IRQ haben.

CU

 

[spoky]

Hallo,

irq-sharing kann man bei mir nicht als Ursache annehmen. Meine beiden hfc-karten haben jeweils einen eigenen irq. Trotzdem kam es zu:

kernel: zaphfc: sync lost, pci performance too low. you might have some cpu throtteling enabled.

# cat /proc/interrupts
           CPU0       CPU1
  0:  144010833          0          XT-PIC  timer
  1:          8          0          XT-PIC  i8042
  2:          0          0          XT-PIC  cascade
  3: 1150781409          0          XT-PIC  zaphfc
  4:       3101          0          XT-PIC  dpti0
  5: 1150805471          0          XT-PIC  zaphfc
  7:      14461          0          XT-PIC  b1isa-150
  9:    4772177          0          XT-PIC  ide2, uhci_hcd
 11:    3577531          0          XT-PIC  eth0
 14:     166760          0          XT-PIC  ide0
NMI:          0          0
LOC:  144016408  144016395
ERR:          0
MIS:          0

mfg spoky

 

[H_I_M]

Bei mir trat das Problem immer bei zugriffen auf die HDD auf (Datei suchen). Nun habe ich meine Kernel wie folg konfiguriert (siehe Screenshot von make xconfig)

CU

 

[LarsAC]

Ich habe exakt das gleiche Problem, ebenfalls mit einem Dual PIII-700 SMP.
Vielleicht liegt da das Problem?

Was mich wundert ist, dass das Problem definitiv nicht bei hoher Last auftritt (vorzugsweise niemand eingeloggt, Asterisk nicht am laufen).

Lars