.titleBar { margin-bottom: 5px!important; }

HFC-S-Karte erzeugt nur wenige Interrupts

Dieses Thema im Forum "Asterisk ISDN mit Bristuff (hfc, zaptel)" wurde erstellt von gda, 8 Nov. 2005.

  1. gda

    gda Neuer User

    Registriert seit:
    8 Nov. 2005
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo,

    Ich benutze zaptel 1.0.9.2 mit bristuff-0.2.0-RC8o und florz-patch.
    Außerdem habe ich zaphfc noch mit der PCI-Vendor-ID von meiner
    noname-hfc-s karte gepatcht.
    Zaphfc lädt ohne Fehlermeldung, dmesg sagt allerdings unter anderem "zaphfc: hfc busy".

    Wenn ich jetzt mit cat /proc/interrupts nachsehe, dann erhöht sich die
    Anzahl Interrupts nur sehr wenig. Ich habe igendwo gelesen, dass die Karte 1000 Interrupts pro Sekunde erzeigen soll. Das Programm zttest zeigt auch nach mehreren Minuten nur 0 Durchläufe an.
    Der Interrupt wird nicht geshared, wäre ja auch wohl kein Problem wegen
    des Florz-Patches.

    Verstehe ich etwas falsch? Ist meine Karte kaputt? Kann mir da jemand
    weiterhelfen?

    Grüße
    Gerald
     
  2. britzelfix

    britzelfix Gesperrt

    Registriert seit:
    28 Mai 2004
    Beiträge:
    1,099
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Braunschweig
    @gda

    Der Treiber muß sich fehlerfrei laden können. Offensichlich
    befindet sich schon ein anderer zaphfc im Speicher "lsmod"
    Wenn sich dieser nicht mit "rmmod zaphfc" entladen lässt,
    dann bleibt nur noch ein Reboot übrig. Ob der Treiber fehlerfrei
    lädt kann man sich dann mit "dmesg" ansehen.

    Gruß
    britzelfix
     
  3. gda

    gda Neuer User

    Registriert seit:
    8 Nov. 2005
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @brizelfix

    die Meldung "zaphfc: hfc busy" kommt tatsächlich nur weil ich vergessen hatte vor einem neuen Versuch das Modul zu entladen. Das ich die Meldungen mit dmesg sehen kann weiss ich, sonst hätte ich diese Meldung kaum sehen können. Ich kenne mich sogar etwas mehr aus und habe ein paar zusätzliche printk-statements in die Interrupt-Routine eingebaut und weiss deshalb, dass die Karte nach wenigen Augenblicken aufhört interrupts zu generieren. Es hätte ja auch sein können, dass die Interrupts noch erzeugt werden, aber die Interrupt-Routine meint sie wäre nicht zuständig. Ich habe den absolut gleichen (weil über selbstgebaute RPMs installiert) Software-Stand auf zwei weiteren Rechnern ausprobiert. Auf einem 1 GHz P III werden fortlaufend interrupts erzeugt, genau wie erwartet. Auf einem zum ersten Rechner baugleichen hören die Interrupts einfach auf. Es kommt auch nicht die sonst übliche Meldung vom Kernel, dass er den Interrupt disabled hat, weil sich keiner darum kümmert. Ich hatte zwar das Gefühl mit ein paar Bios-Einstellungen, etwas mehr Interrupts zu bekommen, aber irgendwann war immer Schluss. Schade, schien mir eine ideale Hardware-Basis zu seien. Ohne Lüfter, wenig Stromverbrauch ...

    Gruß
    Gerald
     
  4. gda

    gda Neuer User

    Registriert seit:
    8 Nov. 2005
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ich frage mich greade, ob ich nicht den florz patch rausnehmen sollte und stattdessen RTAI ausprobieren sollte. Der RTAI-Treiber benutzt ja nicht den Interrupt von der Karte sondern den von einem Timer. Wenn nur der Interrupt der Karte nicht mehr ankommt, die Karte aber sonst ansprechbar bleibt, dann könnte das die Lösung sein.
    Bevor ich mir die Arbeit mache und unseren Kernel für RTAI patche, hat hier vielleicht jemand eine Meinung dazu?

    Gruß
    Gerald
     
  5. britzelfix

    britzelfix Gesperrt

    Registriert seit:
    28 Mai 2004
    Beiträge:
    1,099
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Braunschweig
    @gda

    Es kommt sehr häufig vor, daß
    die Treiberversion mit der Kernelversion
    nicht übereinstimmt. Es hat kein Sinn
    darüber zu spekulieren, sondern hier mal
    Infos liefern. Bitte Auszüge von "dmesg"
    nachdem versucht wurde den Treiber zu landen.
    Was sagt "modinfo zaptel" "modinfo zaphfc"
    was sagt "find /lib/modules/`uname -r`|grep zap" ?
    Wird der Kernel verdorben (tainted) ?

    Gruß
    britzelfix
     
  6. gda

    gda Neuer User

    Registriert seit:
    8 Nov. 2005
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @britzelfix

    ich habe zwar keine Ahnung warum nicht übereinstimmende Treiber- und Kernelversionen auf dem einen Rechner arbeiten sollen und auf dem anderen nicht, aber bitte:

    # dmesg
    Zapata Telephony Interface Registered on major 196
    zaphfc: no version for "zt_receive" found: kernel tainted.
    zaphfc: jitterbuffer size: 1
    PCI: Found IRQ 10 for device 0000:00:06.0
    zaphfc: CCD/Billion/Asuscom 2BD0 configured at mem 0xc483c000 fifo 0xc1238000(0x1238000) IRQ 10 HZ 100
    zaphfc: Card 0 configured for NT mode
    zaphfc: Card 0 configured for master mode
    zaphfc: 1 hfc-pci card(s) in this box.
    zaphfc: card 0 layer 1 state = G2
    zaphfc: card 0 layer 1 state = G3

    # modinfo zaptel
    filename: /lib/modules/2.6.13-2ts/misc/zaptel.ko
    author: Mark Spencer <markster@linux-support.net>
    description: Zapata Telephony Interface
    license: GPL
    parmtype: debug:int
    parmtype: deftaps:int
    vermagic: 2.6.13-2ts 586 REGPARM 4KSTACKS GRSECURITY gcc-3.4
    depends: crc-ccitt
    srcversion: 77B3D963DE19BA27FB33978

    # modinfo zaphfc
    filename: /lib/modules/2.6.13-2ts/misc/zaphfc.ko
    description: HFC-S PCI A Zaptel Driver
    author: Klaus-Peter Junghanns <kpj@junghanns.net>
    license: GPL
    parmtype: modes:i
    parmtype: debug:i
    parmtype: sync_slave:i
    parmtype: timer_card:i
    parmtype: jitterbuffer:i
    vermagic: 2.6.13-2ts 586 REGPARM 4KSTACKS GRSECURITY gcc-3.4
    depends:
    srcversion: 29645EDB5EA8972E5AEBB67


    # find /lib/modules/`uname -r`|grep zap
    /lib/modules/2.6.13-2ts/misc/qozap.ko
    /lib/modules/2.6.13-2ts/misc/zaphfc.ko
    /lib/modules/2.6.13-2ts/misc/zaptel.ko

    # dmesg | grep tainted
    zaphfc: no version for "zt_receive" found: kernel tainted.

    # cat /proc/zaptel/1
    Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [NT] layer 1 ACTIVATED (G3)" AMI/CCS

    1 ZTHFC1/0/1 Clear
    2 ZTHFC1/0/2 Clear
    3 ZTHFC1/0/3 HDLCFCS

    # cat /proc/interrupts | grep zaphfc
    10: 15 XT-PIC zaphfc

    Jetzt bin ich aber mal gespannt

    Gerald
     
  7. britzelfix

    britzelfix Gesperrt

    Registriert seit:
    28 Mai 2004
    Beiträge:
    1,099
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Braunschweig
    @gda

    das ist allerdings sehr spannend. Ich frage mich grade,
    warum der Kernel tainted wird, obwohl es danach aussieht
    das Du dieselbe Version wie der Kernel verwendest.

    Wenn Du sagst, daß der Interrupt nicht "shared" ist, dann
    würde ich mal versuchen ohne Patches die Module zu übersetzen.
    Damit "tainted" nicht auftritt müssen gleiche
    Kernel-Header & Compiler verwendet werden wie sie für den
    Kernel gebraucht wurden. Das muß nicht die Ursache sein,
    ist aber möglich. Sonst kann es auch an der Hardware liegen.
    Bin da auch ziemlich ratlos.

    Gruß
    britzelfix
     
  8. gda

    gda Neuer User

    Registriert seit:
    8 Nov. 2005
    Beiträge:
    12
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @britzelfix

    Ich bin einer der Entwickler der verwendeten Distribution, Kernel-Header & Compiler sind gleich, Punkt. Wir verwenden eine spezielle Entwicklungsumgebung (mach) die
    sicherstellt, das jeder der Entwickler die gleiche Umgebung hat.

    Die folgenden RPM-Ausgaben zeigen, dass die RPMs aus der selben Quelle stammen und zum verwendeten Kernel gehören. Unser Kernel lässt das Laden nicht passender
    Module nicht zu.

    # rpm -qi zaptel
    Name : zaptel Relocations: (not relocatable)
    Version : 1.0.9.2 Vendor: (none)
    Release : 7gd Build Date: Sun Nov 6 19:41:37 2005
    Install Date: Mon Nov 14 23:54:16 2005 Build Host: sn41g2.dachsweb.home
    Group : contrib Source RPM: zaptel-1.0.9.2-7gd.src.rpm
    Size : 352934 License: GPL
    Signature : (none)
    URL : http://www.asterisk.org
    Summary : Digium FXS/FXO drivers.
    Description :
    Asterisk is a complete PBX in software. It runs on Linux and provides
    all of the features you would expect from a PBX and more. If you want
    to interface with POTS and are using Digium hardware, the Zaptel drivers
    support these cards.

    # rpm -qi kernel-module-zaptel-2.6.13-2ts
    Name : kernel-module-zaptel-2.6.13-2ts Relocations: (not relocatable)
    Version : 1.0.9.2 Vendor: (none)
    Release : 7gd Build Date: Sun Nov 6 19:41:37 2005
    Install Date: Mon Nov 14 23:59:24 2005 Build Host: sn41g2.dachsweb.home
    Group : System Environment/Kernel Source RPM: zaptel-1.0.9.2-7gd.src.rpm
    Size : 2911175 License: GPL
    Signature : (none)
    URL : http://www.asterisk.org
    Summary : Digium kernel drivers.
    Description :
    Asterisk is a complete PBX in software. It runs on Linux and provides
    all of the features you would expect from a PBX and more. If you want
    to interface with POTS and are using Digium hardware, the Zaptel drivers
    support these cards.

    Wenn man mal googelt stellt man fest, dass diese spezielle tainted-Meldung immer wieder auftaucht, ohne dass Sie jemals ein Problem war.

    Ausserdem habe ich doch geschrieben, dass dieselbe Karte und dieselbe Software auf
    einem anderen Rechner läuft, was ja wohl ganz klar den Schluss zulässt, dass es an
    der Rechnerhardware liegt, oder?

    Darf ich jetzt wieder Spekulieren? Vielleicht möchte ja ein Anderer auf meine Fragen
    eingehen.

    Gruß
    Gerald