libusb linux "timeout async cancel failed -5 errno=22"

[A. C. (michael1988)]

Hallo,
ich bin gerade dabei mit libusb 1.0.9 einen bulk transfer umzusetzen.
Die Systemarchitektur, mit der ich arbeite ist leider so gebaut, dass 
der gesamte Code in einer Schrittschaltkette threads nur simuliert, da 
das System gewachsen ist und früher auf einem einkernigen Prozessor 
lief.

Die bisherige Implementierung, dich ich vor mir habe, verwendet die 
synchrone api, die Pakete in einen Buffer mit maximal 32678 Bytes liest 
mit einem Timeout von 3ms, was das ganze System extrem ausbremst und 
sehr instabil ist. Ich bekomme bei Paketen um 6k von der libusb die 
Debugausgabe: "timeout async cancel failed -5 errno=22", dann schlägt 
die Kommunikation fehl.

Hat jemand eine Idee, was da dahinter steckt? Wenn ich die asynchrone 
API verwende, passiert das nicht.

Viele Grüße

[Stefan F. (Gast)]

> timeout async cancel failed -5 errno=22

Ich habe die Meldung schon öfters in Zusammenhang mit ISP 
Programmieradaptern gesehen. Aber was sie bedeutet, weiß ich auch nicht.

[Clemens L. (c_l)]

A. C. schrieb:
> mit einem Timeout von 3ms

Nimm 300 ms, oder besser 3000 ms.

> "timeout async cancel failed -5 errno=22", dann schlägt die Kommunikation
> fehl.
>
> Hat jemand eine Idee, was da dahinter steckt?

5 = EIO, 22 = EINVAL

Nach 3 ms waren die Daten noch nicht übertragen, also wurde versucht, 
den Transfer abzubrechen. Das hat nicht funktioniert. (Vielleicht war 
dann der Transfer doch erledigt ...)

[Jim M. (turboj)]

A. C. schrieb:
> die Pakete in einen Buffer mit maximal 32678 Bytes liest
> mit einem Timeout von 3ms

Vieeel zu kurz. Das Timeout killt den URB bevor die Transaktion beendet 
werden kann - und ich müsste jetzt nachschauen ob da nicht auch Deine 
Daten weggeschmissen werden.

Bei USB Full Speed brauchen 1KB Daten jeweils ungefähr 1ms, denn da 
gehen netto nur ca. 1 MByte/Sec durch das Drähtepaar.

Puffer oberhalb von 4KB machen bei libusb wenig Sinn, denn IIRC ist ein 
URB selbst nur max 4KB groß.


Was man aber machen kann ist mehrere Puffer hintereinander scharf zu 
schalten (submit), die alle jeweils längere Teimouts haben (500ms, 1 
Sekunde oder ähnlich).

Timeouts muss man eigentlich immer gesonder (und nicht als Fehler) 
behandeln, denn das ein USB Gerät mal eine Weile nix zu sagen hat ist je 
nach Protokoll völlig normal.

Korrekte (Fehler-)Behandling ist bei sich überschneidenen Transaktionen 
allerdings nicht mehr völlig trivial.

[Jim M. (turboj)]

Jim M. schrieb:
> Bei USB Full Speed brauchen 1KB Daten jeweils ungefähr 1ms,

Mist, verschrieben. Sollte mindestens 1ms heissen, denn das USB device 
kann beliebig langsam senden.

[Clemens L. (c_l)]

Jim M. schrieb:
> Timeouts muss man eigentlich immer gesonder (und nicht als Fehler)
> behandeln, denn das ein USB Gerät mal eine Weile nix zu sagen hat ist je
> nach Protokoll völlig normal.

Dann sollte man überhaupt kein Timeout benutzen.