Hallo, sind diese Meldungen "normal" das geht die ganze Zeit so dahin ?? -- MfG / Regards Günther J. Niederwimmer
Hallo!
sind diese Meldungen "normal" das geht die ganze Zeit so dahin ??
Wo hast Du den Treiber her? Selbst übersetzt? Die Ausgaben sehen so aus, als kämen sie aus einem Debug-Treiber. Diese sind - als Debug-Ausgaben - nicht für den normalen Betrieb gedacht und sind daher im "normalen" Treiber nicht zu beobachten, weil deaktiviert. Gruß, =OF= -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Hallo!
Wo hast Du den Treiber her? Selbst übersetzt?
Nein, ist der Treiber vom 2.4.19 Kernel (k_deflt.i586) , ist aber egal war
auch schon bei der erst(neu)installation so ??
*grübel* Das ist kein AVM-Treiberpaket, keine offizielle SuSE-Kernelversion von der SuSE 8, oder? Auf jeden Fall wurde der Treiber falsch übersetzt, wenn da Debug-Ausgaben enthalten sind. Wenn Dich das wirklich stört, dann mußt Du Dir den Quellcode besorgen und den Treiber selbst neu er- zeugen... Gruß, =OF= -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Wednesday 28 August 2002 09:04, Günther J. Niederwimmer wrote:
sind diese Meldungen "normal" das geht die ganze Zeit so dahin ??
Das sind Debug-Meldungen, wie OF das schon richtig erklärt hat. Allerdings passiert da IMHO etwas seltsames: Zu Deiner Info mal übersetzt, was da passiert: Aug 28 00:15:55 server kernel: fcpci: PUT_MESSAGE(appl:1,cmd:0x05,subcmd:0x80) LISTEN_REQ Aug 28 00:15:55 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0x05,subcmd:0x81) LISTEN_CONF - -> hier hat irgendeine Anwendung dem CAPI gesagt, er solle auf Anrufe hören (_REQuest) und der CAPI bestätigt (_CONFirm) Aug 28 00:16:00 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0xFF,subcmd:0x82) Aug 28 00:16:10 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0xFF,subcmd:0x82) Aug 28 00:16:20 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0xFF,subcmd:0x82) MANUFATURER_IND - -> nett. Hier teilt der Treiber der Anwendung etwas mit (_INDication), was vendor-spezifisch ist. Habe ich auch noch nicht gesehen ;-) Aug 28 00:16:55 server kernel: fcpci: PUT_MESSAGE(appl:1,cmd:0x05,subcmd:0x80) Aug 28 00:16:55 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0x05,subcmd:0x81) LISTEN_REQ & _CONF - -> siehe oben Aug 28 00:17:00 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0xFF,subcmd:0x82) Aug 28 00:17:50 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0xFF,subcmd:0x82) MANUFACTURER_IND, s.o. und so geht's dann weiter. Diese ständige Wiederholung derselben Befehle deutet für mich auf eine irgendwie fehlerhafte CAPI-Anwendung hin. Oder sie gerät durch die vendor-spezifischen Mitteilungen, die sie wohl nicht versteht, irgendwie durcheinander und versucht eine Neu-Initialisierung. LISTEN_REQ ist typischerweise das erste, was eine Anwendung so an den CAPI schickt - damit sagt sie ihm, dass er überhaupt auf Anrufe hören soll und bekommt damit überhaupt erst eine Nachricht, wenn ein Anruf eingeht. Was für CAPI-Anwendung hast Du denn da laufen? - -- Ciao, Gernot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9bH5yk997/GGeSeIRAkVZAJsFhVrbmqR3yp7RdkvCck724QdSlwCgqcel LpIq25ac7D9W/8+UiwjEdPQ= =5Ukl -----END PGP SIGNATURE-----
Hallo!
- -> hier hat irgendeine Anwendung dem CAPI gesagt, er solle auf Anrufe hören (_REQuest) und der CAPI bestätigt (_CONFirm)
- -> nett. Hier teilt der Treiber der Anwendung etwas mit (_INDication), was vendor-spezifisch ist. Habe ich auch noch nicht gesehen ;-)
und so geht's dann weiter. Diese ständige Wiederholung derselben Befehle deutet für mich auf eine irgendwie fehlerhafte CAPI-Anwendung hin.
Läuft vielleicht soetwas wie KISDNWatch? ;-) Gruß, =OF= -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Wednesday 28 August 2002 09:44, foskaty@gmx.de wrote:
- -> hier hat irgendeine Anwendung dem CAPI gesagt, er solle auf Anrufe
hören
(_REQuest) und der CAPI bestätigt (_CONFirm)
- -> nett. Hier teilt der Treiber der Anwendung etwas mit (_INDication), was vendor-spezifisch ist. Habe ich auch noch nicht gesehen ;-)
und so geht's dann weiter. Diese ständige Wiederholung derselben Befehle deutet für mich auf eine irgendwie fehlerhafte CAPI-Anwendung hin.
Läuft vielleicht soetwas wie KISDNWatch? ;-)
Aber auch der muss nur einmal ein LISTEN_REQ absetzen und nicht jede Minute einmal. Mit LISTEN_REQ wird die Karte/der Treiber ja nur in den Listen-Modus gesetzt und bekommt dann automatisch vom CAPI die eingehenden Anrufe (die auf die eingestellten Bedingungen passen) mitgeteilt. - -- Ciao, Gernot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD4DBQE9bIhKk997/GGeSeIRAqvSAJdUhvIrHj2N0CUJsbGDH4FotwBCAJ0SLTJs tzYSho/sqpSQkVoLxTN31g== =oA4u -----END PGP SIGNATURE-----
On Wed, Aug 28, 2002 at 09:44:03AM +0200, foskaty@gmx.de wrote:
Hallo!
- -> hier hat irgendeine Anwendung dem CAPI gesagt, er solle auf Anrufe hören (_REQuest) und der CAPI bestätigt (_CONFirm)
- -> nett. Hier teilt der Treiber der Anwendung etwas mit (_INDication), was vendor-spezifisch ist. Habe ich auch noch nicht gesehen ;-)
und so geht's dann weiter. Diese ständige Wiederholung derselben Befehle deutet für mich auf eine irgendwie fehlerhafte CAPI-Anwendung hin.
Läuft vielleicht soetwas wie KISDNWatch? ;-)
Ich vermute eher das capidrv laeuft und ueber die MANUFACTOR Sachen werden die DTRACE Daten fuer isdnlog uebertragen. -- Karsten Keil SuSE Labs ISDN development
Hallo,
sind diese Meldungen "normal" das geht die ganze Zeit so dahin ??
Das sind Debug-Meldungen, wie OF das schon richtig erklärt hat. Allerdings passiert da IMHO etwas seltsames:
- -> hier hat irgendeine Anwendung dem CAPI gesagt, er solle auf Anrufe hören (_REQuest) und der CAPI bestätigt (_CONFirm)
Ja aber welche, das einzige was da läuft ist Capi for Hylafax
- -> nett. Hier teilt der Treiber der Anwendung etwas mit (_INDication), was vendor-spezifisch ist. Habe ich auch noch nicht gesehen ;-)
Ist eine "normale" AVM PCI und eine Teles 16.0 ISA die im Rechner sind.
Aug 28 00:16:55 server kernel: fcpci: PUT_MESSAGE(appl:1,cmd:0x05,subcmd:0x80) Aug 28 00:16:55 server kernel: fcpci: GET_MESSAGE(appl:1,cmd:0x05,subcmd:0x81) LISTEN_REQ & _CONF
und so geht's dann weiter. Diese ständige Wiederholung derselben Befehle deutet für mich auf eine irgendwie fehlerhafte CAPI-Anwendung hin.
Es läuft aber nur der Hylafax-(Capi)
Oder sie gerät durch die vendor-spezifischen Mitteilungen, die sie wohl nicht versteht, irgendwie durcheinander und versucht eine Neu-Initialisierung.
Ich habe alles auf dem S0 hängen 3 Telefone und 3 ISDN Karten, man kann aber alles abhängen und doch kommen diese Meldungen ? Ich habe den verdacht das hängt mit der A-ISdn (Global-Call) einstellung zusammen, denn ich kann machen was ich will, Fax bringe ich nicht zum laufen? Weder mit einer Sedlbauer Speedfax+ ISA noch AVM usw.
Was für CAPI-Anwendung hast Du denn da laufen? Wie oben beschrieben "eigentlich nichts" ?
-- MfG / Regards Günther J. Niederwimmer
Hallo!
Was für CAPI-Anwendung hast Du denn da laufen?
Wie oben beschrieben "eigentlich nichts" ?
Das muß jetzt mal genau beschnuppert werden, mach' mal einen... " lsof | grep capi " ... und schicke die Ausgabe! Daraus kann man sehen, welche Applika- tionen an dem CAPI-Device lauschen. Gruß, =OF= -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
participants (4)
-
foskaty＠gmx.de -
Gernot Hillier -
Günther J. Niederwimmer -
Karsten Keil