Hallo, ich hab ein Programm geschrieben, dass Daten über eine PCMCIA Synchronous Serial Card überträgt. Leider kommt es hier manchmal vor, dass sich die Karte aufhängt. Dieses Problem lässt sich nur über ein Close() und Open() wieder beheben. Mein Problem ist nun, dass Close() ewig braucht, mehr als eine halbe Minute. Gibt es eine Möglichkeit einen device file descriptor zu zwingen sich zu schließen, also sozusagen -f für die Close() Funktion? Danke schon mal
Nuja, wenn sich die Karte aufhängt, will das close wohl auch nochmal abschliessend was mit ihr besprechen (zB. alle Daten flushen), das dauert dann halt bis zu einem Timeout im Treiber. Du könntest versuchen, den Deskriptor vor dem close mit fcntl auf non-blocking zu setzen.
Hallo das Device ist schon im non-blocking mode. Das Problem ist, ich glaub nicht, dass da irgendein Timer ausläuft. Das würde ja heißen, dass clos() mit nem Fehler beendet wird. Close() returned aber mit 0, also ohne Fehler. Flushen, glaub ich jetzt auch nicht ich führ extra um das auszuschließen vor Close() n flush aus, der ohne Probleme durchläuft.
Lies halt mal das dmesg durch, da drinnen sieht man oft woher der Wind weht.
Alles schon getan. Bringt nur nichts, das der Treiber irgendwie abschmiert bzw. irgendwelche Fehler hat ist mir klar. Dmesg zeigt das auch an, das ein "Output Error" oder "Framing Error" aufgetreten ist. Ich versuch das Teil seit zwei Monaten zum laufen zu bringen. Mit ner Menge "Workarounds" hab ichs jetzt so weit, dass die Übertragung durchläuft und nicht irgendwann immer abbricht. Das Problem ist nur, diese Workarounds machen die Übertragung extrem langsam und der schlimmste Zeitfresser ist halt dieser Hänger in der Close() Funktion. (Und damit wir uns richtig verstehen ich rede von der der Library Close() Funktion und nicht von irgendetwas selbst zusammen gepfuschten). Die Fehlerquelle hab ich auf Treiber oder Hardware eingeschränkt. Hab mich auch schon des an den Hersteller gewendet, aber ich glaub da hab ich jetzt dann alle Applikation Engineers und Linux Development Engineers durch. Und jedes Gespräch lief irgendwie gleich hab. Ich beschreib das Problem, bekomme E-Mail mit Gegenfragen zugeschickt, beantworte alle E-Mail mit gewünschten Zeitmessungen und Durchlaufmessungen, bekomme wieder ne E-Mail mit Fragen zu geschickt, beantworte diese wieder - keine Reaktion mehr. Das was ich jetzt mache ist im Prinzip, dass ganze so zu optimieren das man damit einiger Masen vernünftig Arbeiten kann, bis mein Chef mir Geld gibt um ne Alternative zu finden. Der Hänger in der Close() Funktion kostet jedes mal immer ca. 30s - 60s wenn man das irgendwie umgehen könnte würde es den Dateitransfer extrem beschleunigen und man müsste nicht 15 min warten um eine 1 MB Datei mit 115200 baud zu übertragen...
Thomas Br schrieb: > Das Problem ist, ich glaub nicht, dass da irgendein Timer ausläuft. Für mich klingt das genau danach. Der Treiber versucht, das Gerät zu deinitialisieren, bekommt aber keine Antwort und wartet deshalb. Oder er versucht, regelmäßig irgendein Kommando abzusetzen, so lange bis es klappt oder eine bestimmte Maximalzahl von Versuchen durchgeführt wurden. > Das würde ja heißen, dass clos() mit nem Fehler beendet wird. Close() > returned aber mit 0, also ohne Fehler. Das kommt drauf an, ob der Treiber das entsprechend implementiert hat. Vielleicht hat der Programmierer speziell in close() diesen Fall nicht explizit als Fehler bedacht, und da das Problem bei ihm bisher so nicht aufgetreten ist, hat er auch nicht gemerkt, daß da kein Fehler zurückgemeldet wird.
Rolf Magnus schrieb: > Vielleicht hat der Programmierer speziell in close() diesen Fall nicht > explizit als Fehler bedacht, und da das Problem bei ihm bisher so nicht > aufgetreten ist, hat er auch nicht gemerkt, daß da kein Fehler > zurückgemeldet wird Das kann ja alles sein, und davon geh ich aus dass Close() auf irgendeine Rückantwort wartet, alles andere wäre ja komisch. Aber wie gesagt ich such was wie rm -f, das egal was der Treiber gerade macht, der einfach den File Descriptor schließt damit die Vebindung "reseted" wird.
Sourcecode zum Treiber gibts nicht? Meistens ist der close-Teil recht klein, da sollte man den Hänger schon einfach finden.
Andere herangehensweise: Was passiert, wenn du kein Close aufrufst? Ist dann ein open möglich? Bei manchen Treiber geht dies, wenn sie nicht einen Single open only implementiert haben. Wenn dem so ist, könntest du das Close 3evtl. in einen Thread auslagern oder ganz weglassen. Ansonsten empfehle ich dir, lad dir die Kernel-Qellen herunter und suche dort. Evtl. hilft es auch, wenn du mit deinem ganzen Aufbau zum Hersteller fährst, offenbar ist es dort so, das sie es nicht nachstellen können.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.