Forum: PC-Programmierung Linux Devicefile schließen dauert ewig


von Thomas B. (thomasbr)


Lesenswert?

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

von Georg A. (georga)


Lesenswert?

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.

von Thomas B. (thomasbr)


Lesenswert?

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.

von Max D. (max_d)


Lesenswert?

Lies halt mal das dmesg durch, da drinnen sieht man oft woher der Wind 
weht.

von Thomas B. (thomasbr)


Lesenswert?

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...

von Rolf Magnus (Gast)


Lesenswert?

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.

von Thomas B. (thomasbr)


Lesenswert?

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.

von Georg A. (georga)


Lesenswert?

Sourcecode zum Treiber gibts nicht? Meistens ist der close-Teil recht 
klein, da sollte man den Hänger schon einfach finden.

von Sven (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.