Einer Festplatte das Einschlafen abgewöhnen

[DonLucio]

Eine meiner USB-Platten macht Probleme: Nach dem Anstöpseln wird ein Laufwerksbuchstabe zugeordnet (x:) und ich kann damit arbeiten. Lesen, Schreiben, alles. Nach einer gewissen Zeit der Inaktivität legt sich die HD schlafen. Im Prinzip ist nix dagegen einzuwenden. Aber ich würde der Platte das gern abgewöhnen.

Hintergrund ist folgender:

Wenn ich nach einer längeren Pause auf die Platte wieder zugreife, geschieht Abscheuliches: Ich kann noch hören, wie die Platte wieder hochfährt, aber das Programm hängt sich auf und der Mauszeiger friert ein. Das System läuft weiter, ich kann mittels Tastatur alles machen, was man halt via Keyboard machen kann. Aber alles, was irgendwie mit der USB-Platte zu tun hat, z.B. Dateisystem abmelden, geht nicht. Selbst das Killen des Prozesses, der gerade auf die Platte zugreifen wollte und damit den Mousefreeze ausgelöst hat, rührt sich nicht von der Stelle. Auch das Advanced Kill im TOP geht ins Leere.

Obgleich das AOS selbst noch läuft, kann ich nix (Sinnvolles) tun. Auch <ctrl><alt>del hängt sich auf. Also Power off.

Und danach gut 20 Minuten warten, bis der Chkdsk über die USB-Platte gelaufen ist. Das ist äußerst lästig.

Meine Frage wäre: Gibt es ein OS/2-Tool, das in der Platte den Sleep-Modus abschaltet? Meinetwegen dauerhaft. Im BIOS (Hewlett Packard!) hab' ich nichts dazu gefunden.

Falls es von Interesse ist:
Es sieht so aus, als ob das Freeze nur passiert, wenn in den Schlafmoduus hinein ein Schreibvorgang gestartet wird. Durch einen nur-lesenden Zugriff ist es möglich, die Platte ohne Schaden aufzuwecken und zum Arbeiten zu bewegen.

Danke,
Don Lucio.

[Andi B.]

Welchen USB Treiber Stack und Version verwendest du? Ich kenne das Problem. Nur dauert bei mir chkdsk dann fast 2h (2TB).

[aschn]

Obgleich das AOS selbst noch läuft,

Das meiste wird schon tot sein.

kann ich nix (Sinnvolles) tun. Auch <ctrl><alt>del hängt sich auf. Also Power off.

Das ist normal bei Hardware- und Treiberproblemen. Früher dachte ich mal mit Multitasking gibt es diesen Mist nicht mehr, aber sie haben diesen ganzen Hardwarezugriff nicht vom Rest des Systems getrennt.

Würde mich mal interessieren, welches System oder welche Architektur das heute deutlich besser macht. Ich kenne wahrscheinlich noch keins.

[DonLucio]

Welchen USB Treiber Stack und Version verwendest du?

Genau 1 Jahr alt:

Code: Alles auswählen

USBD             .SYS      47,820 .a.. 19-03-20 21:45:26
USBEHCD          .SYS      60,068 .a.. 19-03-20 21:45:28
USBHID           .SYS      23,388 .a.. 19-03-20 21:45:28
USBKBD           .SYS      50,448 .a.. 19-03-20 21:45:28
USBMOUSE         .SYS      33,892 .a.. 19-03-20 21:45:28
USBOHCD          .SYS      48,472 .a.. 19-03-20 21:45:26
USBPRT           .SYS      48,102 .a.. 19-03-20 21:45:30
USBRESMG         .SYS      29,600 .a.. 19-03-20 21:45:32
USBUHCD          .SYS      42,900 .a.. 19-03-20 21:45:26

Ich kenne das Problem. Nur dauert bei mir chkdsk dann fast 2h (2TB).

Und passiert bei dir auch immer nur im Sleep-Modus?

[DonLucio]

Würde mich mal interessieren, welches System oder welche Architektur das heute deutlich besser macht. Ich kenne wahrscheinlich noch keins.

Liegt vermutlich an grundlegender Architektur der altehrwürdigen Intel x86-Systeme.
Auf IBM-Mainframes (/360 ff. und zOS) habe ich sowas noch nie erlebt. Dort funktioniert ja preemptives Multitasking auch schon seit über 50 Jahren.

Na, was soll's .... S'ist wie es ist.

[Andi B.]

Welchen USB Treiber Stack und Version verwendest du?

Genau 1 Jahr alt:

Code: Alles auswählen

USBD             .SYS      47,820 .a.. 19-03-20 21:45:26
USBEHCD          .SYS      60,068 .a.. 19-03-20 21:45:28
USBHID           .SYS      23,388 .a.. 19-03-20 21:45:28
USBKBD           .SYS      50,448 .a.. 19-03-20 21:45:28
USBMOUSE         .SYS      33,892 .a.. 19-03-20 21:45:28
USBOHCD          .SYS      48,472 .a.. 19-03-20 21:45:26
USBPRT           .SYS      48,102 .a.. 19-03-20 21:45:30
USBRESMG         .SYS      29,600 .a.. 19-03-20 21:45:32
USBUHCD          .SYS      42,900 .a.. 19-03-20 21:45:26

Ich kenne das Problem. Nur dauert bei mir chkdsk dann fast 2h (2TB).

Und passiert bei dir auch immer nur im Sleep-Modus?

Bitte "bldlevel usbd.sys" und "bldlevel usbmsd.add".

Ich denke auch Lars würde es interessieren, ob es sich um "seinen" Stack handelt, oder den von David. Ich habe/hatte dieses "Sleep" Problem immer wieder über viele Jahre. AFAIR hat mir Lars das mal mit einer Festplatte wo ich das reproduzieren konnte, gefixed. Erst vor einigen Tagen hatte ich ein ähnliches Problem auf einem anderen Rechner mit dem neuesten AN Stack. Die Auswirkung war gleich, Hänger beim aufwecken der externen USB-HDD, aber dann einen Trap 0003 im JFS. Auch wenn's ähnlich aussieht, könnte das eine andere Ursache gehabt haben.

Darum muss man bei solchen Fehlerbeschreibungen genau sein. Also welcher Stack genau - bldlevel, welches Programm ist ev. auch hilfreich. Außer du willst nicht die Ursache bekämpfen, sondern nur einen work around wie du das im Thread Titel schreibst. Dazu kann ich aber nichts beitragen, außer ein script welches halt regelmäßig liest/schreibt. Aber das hättest du selbst sicher schneller geschrieben als den Text hier, wenn dir diese Lösung gefallen hätte.

[DonLucio]

Bitte "bldlevel usbd.sys" und "bldlevel usbmsd.add".

Bis auf "Description" und die Sekunde im Timestamp identisch:

Code: Alles auswählen

■■■»bldlevel c:\os2\boot\usbd.sys
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Arca Noae LLC:12.04#@##1## 19 Mar 2020 21:45:26     DAZAR1
 ::::::@@USB Driver (32 bit) (c) 2020 Arca Noae LLC
Vendor:          Arca Noae LLC
Revision:        12.04
Date/Time:       19 Mar 2020 21:45:26
Build Machine:   DAZAR1
File Version:    12.4
Description:     USB Driver (32 bit) (c) 2020 Arca Noae LLC

Außer du willst nicht die Ursache bekämpfen, sondern nur einen work around wie du das im Thread Titel schreibst.

Natürlich würde ich am liebsten die Ursache bekämpfen, aber ich bin da ziemlich desillusioniert. Das Ticket-System bei netlabs ist für mich - der ich kein Systemprogrammierer bin - ein unzugängliches country of mistery, und ArcaNoae antwortet sowieso nicht. Also bin ich schon mit der kleinsten praktikablen Lösung, nenne es gern Workaround, zufrieden.

...außer ein script welches halt regelmäßig liest/schreibt. Aber das hättest du selbst sicher schneller geschrieben als den Text hier, wenn dir diese Lösung gefallen hätte.

Genau! So ein Script war meine erste Idee, bevor ich hier ans Forum ging. Leider nur verfügt meine USB-Platte über ein so intelligentes Cache-Management, dass sie die Platte trotzdem schlafen legt, wenn andauernd dieselben Daten gelesen + geschrieben werden. Also mußte ich eine etwas aufwendigere Logik programmieren, mit Random-Funktion, die weiträumig unterschiedliche Daten erzeugt und irgendwann wieder von vorn anfängt. Aber nicht das Gesamt-IO-System zu sehr fordert.

Das funktioniert zwar inzwischen, aber ich komme mir halt doch ziemlich blöd vor, so einen sinnlosen Datenschaufelbagger ständig am Laufen zu halten ... wo ein einfaches Ausschalten der Sleep-Funktion das Problem aus der Welt schaffen (nicht lösen!) würde.

Auf meiner Linux-NAS gibt es so einen Befehl. Aber im OS/2 aka AOS?

Gruß,
Don Lucio.

[Andi B.]

Natürlich würde ich am liebsten die Ursache bekämpfen, aber ich bin da ziemlich desillusioniert. Das Ticket-System bei netlabs ist für mich - der ich kein Systemprogrammierer bin - ein unzugängliches country of mistery, und ArcaNoae antwortet sowieso nicht. Also bin ich schon mit der kleinsten praktikablen Lösung, nenne es gern Workaround, zufrieden.

Naja, netlabs tickets funktionieren wenn man sich mal anmeldet hat. Das war bei mir vor vielen Jahren, aber ich habe gehört, dass es da neuerdings Probleme geben soll. Nur, jetzt wissen wir, dass du ja Davids (DAZAR1) Stack und nicht Lars Version verwendest. Also wäre es sinnlos, Lars mit einem netlabs ticket zu sekkieren. Bei AN gibt es mittlerweile 12.7. Und wenn du mit diesem Problem bei AN ein Ticket erstellst, wirst du wohl zuerst auf die 12.7er Version updaten müssen. Aber antworten tut AN meiner Erfahrung immer. Und meist auch sehr schnell. Dein "...und ArcaNoae antwortet sowieso nicht" kann ich nicht nachvollziehen.

Wenn du sogar einen Linux Befehl dazu kennst, wäre diese Info (und welcher es den ist) ev. auch z.B. schon im Betreff sinnvoll gewesen. Ev. hätte hier dann jemand einen anderen Lösungsweg gewußt.

[DonLucio]

Dein "...und ArcaNoae antwortet sowieso nicht" kann ich nicht nachvollziehen.

Ok, ich hab's lange nicht mehr versucht (bin leider schnell frustrierbar).

Aber ich werde es dann nochmal probieren.

Danke,
Don Lucio.

[Martin Vieregg]

Ich würde gerne umgekehrt meiner SATA-HDD, die ich nur zur Datensicherung verwende, das Schlafen angewöhnen. Gibt es dazu auch schon etwas?

[aschn]

Auf IBM-Mainframes (/360 ff. und zOS) habe ich sowas noch nie erlebt.

Merkwürdiger Vergleich. Hot-Swap wird zwar von einigen Treibern und entsprechender Hardware unterstützt, aber sonst laufen Festplatten gerade bei Servern ohne abzuschalten. Dass man Volumes im laufenden Betrieb um Medien verändern kann, hat damit nichts zu tun, weil das eine andere Ebene ist. Wie oben angedeutet, der Austausch einzelner Festplatten im laufenden Betrieb geht nicht einfach so durch die Architektur. Die CPU und die Schnittstellen drum herum haben wenig mit einem RAID-Controller zu tun.

[erdmann]

Ich hätte zur Lösung des Problems eine Idee: anstelle Daten zu lesen, was ja offensichtlich nicht hilft, könnte man in regelmäßigen Abständen den device descriptor oder einen String descriptor lesen. Diese Art von Control Transfers sollten das USB device daran hindern, sich in den Suspend Modus zu begeben. Könnte man sogar in REXX programmieren. Man würde dazu das USBCALLS REXX Interface benutzen.

[erdmann]

Als Test: kannst du mal den ganzen USB Stack durch meinen ersetzen und schauen ob es da auch auftritt ? Danach kannst du ja dann den AN Stack wieder drüberbügeln.

Das Problem ist, dass sich womöglich nicht nur deine Platte schlafen legt, sondern auch die USB ports selbst, die vom Host Controller bedient werden. Ich kann mich noch daran erinnern, dass ich ziemlich lang in den host controller Treibern (USByHCD.SYS) mit dem USB port suspend/resume herumgemacht habe und ebenso in USBMSD.ADD , damit die Platte wieder gefunden wird wenn das System (vollständig) im Suspend war. Mich würde schon interessieren ob das geholfen hat. Dann könnte man nämlich vielleicht AN darauf hinweisen (obwohl die immer die Tendenz haben es definitiv selbst machen zu wollen. Sie wissen es definitiv am besten).

[DonLucio]

Als Test: kannst du mal den ganzen USB Stack durch meinen ersetzen und schauen ob es da auch auftritt ?

Will ich gern mal machen. Welchen Stack genau soll ich benutzen?

Könnte man sogar in REXX programmieren. Man würde dazu das USBCALLS REXX Interface benutzen.

Ich bin ja leidenschaftlicher Anwender aller möglichen Rx-DLLs. Von einer RxUSB habe ich noch nichts gehört. Kannst du mir da eine Quelle nennen?

Gruß,
Don Lucio.

[erdmann]

Als Test: kannst du mal den ganzen USB Stack durch meinen ersetzen und schauen ob es da auch auftritt ?

Will ich gern mal machen. Welchen Stack genau soll ich benutzen?

Könnte man sogar in REXX programmieren. Man würde dazu das USBCALLS REXX Interface benutzen.

Ich bin ja leidenschaftlicher Anwender aller möglichen Rx-DLLs. Von einer RxUSB habe ich noch nichts gehört. Kannst du mir da eine Quelle nennen?

Gruß,
Don Lucio.

Einfach den ggw. neuesten : 10.238. Ist wie immer auf Hobbes, ggw. glaub ich noch in "incoming"

Das USBCALLS REXX interface ist in ....: USBCALLS.DLL ! Und die Doku ist hier: http://www.edm2.com/index.php/USBCalls. Da USBCALLS immer mitintalliert wird (weil diverse Programme das C Interface nutzen), gibt es auch nichts Neues zu installieren.
Es ist etwas trial und error nötig, bis man da Ergebnisse produziert. Insbesondere muss man wissen, dass Datenpuffer BINÄR sind, da ist also nichts nach REXX strings konvertiert.
Bedeutet also, auf dem Datenpuffer arbeitet man mit der "c2d" (oder "c2x") Funktion und, um little endian Daten richtig als String darstellen zu können, auch mit "reverse". Ich kann da notfalls ein Beispiel beisteuern.

[erdmann]

Du könntest hier schon mal die USB Descriptor Info für deine Platte posten.

Die Info bekommst du entweder in USBRES.EXE oder mittels "lsusb.exe" (portiert von Paul Smedley). Wenn ich die hab können wir dann das REXX script um die Wette programmieren !

Ach noch was: damit du überhaupt weißt, was die USB Descriptor Info bedeutet und welche Standard Device Commands man an ein USB device schicken kann müßtest du in die USB spec (Version 2.0) reinschauen ...

[DonLucio]

Einfach den ggw. neuesten : 10.238. Ist wie immer auf Hobbes, ggw. glaub ich noch in "incoming"

Ja, in Incoming hab ich's gefunden.

Hier nur mal ein Zwischenbericht:
Ich habe also alle *.sys, *.sym, *.add, *.dll (insgesamt 24 Dateien) in die entsprechenden Dirs auf c:\ kopiert (vorher die alten gesichert).

Danach neu gebootet. Alles gut. Bevor ich aber zu dem Test "Schlafenlegen und dann durch einen Schreibvorgang aufwecken" gekommen bin, hatte ich noch eine größere Menge Dateien auf die fragliche USB-Platte kopiert (hat nix mit dem Test zu tun, mußte einfach gemacht werden). Nach etlichen hundert Dateien und anderthalb Stunden Kopierarbeit war Schluß: Mein AOS fiel runter, wie ich es noch nie zuvor erlebt habe. Kein "Trap" o.ä., einfach urplötzlich schwarzer Bildschirm, dann nach 10 Sekunden fing der PC an, neu zu booten.

Sowas hatte ich zuvor noch nie, dennoch: Das muß nichts mit deinen neuen Treibern zu tun haben. Das ganze USB-Geschäft in OS/2 erlebe ich von Anfang an als ziemlich instabil. Und auf meinem PC ist immer allerhand los, gerade während längerer Kopierjobs mache ich jede Menge andere Aufgaben. Im heutigen Fall habe ich gerade eine Datei gedownloadet, als der Blackout passierte. Ist alles sehr unspezifisch und unspektakulär, aber ich halte es für möglich, dass mein Absturz auch mit dem alten USB-Stack passiert wäre.

Gegenwärtig läuft der Chkdsk .... dauert noch ein Weilchen. Dann werde ich den eigentlichen "Sleep+Wake"-Test fahren.

Das USBCALLS REXX interface ist in ....: USBCALLS.DLL ! Und die Doku ist hier: http://www.edm2.com/index.php/USBCalls.

Danke!

Bedeutet also, auf dem Datenpuffer arbeitet man mit der "c2d" (oder "c2x") Funktion und, um little endian Daten richtig als String darstellen zu können, auch mit "reverse". Ich kann da notfalls ein Beispiel beisteuern.

Danke, Wenn's soweit ist, melde ich mich noch mal.

Gruß,
Lutz W.

[DonLucio]

Eine gute und eine schlechte Nachricht:
Mit dem USB-Stack .238 (von Hobbes geholt) gibt's keinen Freeze und keinen System-Absturz mehr.

Allerdings:
Der Versuch, eine Datei auf das schlafende USB-Laufwerk zu schreiben, endete mit einem Fehler ("Err 30"). Im Ergebnis war die Datei angekommen, jedoch mit Dateigröße 0. Die unmittelbare Wiederholung des Kopierversuchs hat dann zum Stillstand der Session geführt (Kommandozeile mit copy-Befehl).

Und am Ende war die Platte auch nicht mehr zu retten. Chkdsk mußte es wieder richten.
Dann aber war sogar die kopierte Datei einwandfrei vorhanden.

Dieser Fehler tritt aber offenbar nur bei Dateien einer bestimmten Größe auf. Eine andere, kleinere Datei (456 Bytes) ließ sich problemlos während des Sleep-Modus draufkopieren. Die andere Datei hatte 46.186 bytes.

Der Fehler läßt sich reproduzieren ...

NACHTRAG (23.3., 13:00 Uhr):
Das oben Gesagte war gestern .... Heute sieht es völlig anders aus!

Es läßt sich *nicht* reproduzieren!
Selbes Gerät, selbe Kopiervorgänge, *anderes* Ergebnis. Ich versteh's nicht.

Auf der Basis der heutigen Tests kann ich sagen: Die .238 läuft tadellos, auch im Suspend-Modus.

Sorry für die Verwirrung. Vielleicht liegt's an meinem USB-Gerät (Marke "Captiva", integriertes System aus USB-Controller und Disk).

Gruß,
Lutz W.

[erdmann]

Du schreibst, mit 10.238 gibt's kein Systemabsturz und keinen Hänger mehr. Aber den monumentalen Crash (ohne Trapscreen) hattest du schon mit 10.238, oder?

Ja, suspend und resume bleiben spannende Probleme. Eigentlich sollte die Platte von selbst aufwachen wenn man auf sie schreiben will (meine WD "My Book" tut das: da hängt das System einen sehr kurzen Moment während die Platte anläuft, dann wird der Datentransfer sauber durchgeführt) aber deine Platte offensichtlich nicht. Dann vielleicht doch die angedachte Hacklösung. Wie gesagt, wenn du mir die descriptor Info geben könntest ...

[DonLucio]

Du schreibst, mit 10.238 gibt's kein Systemabsturz und keinen Hänger mehr. Aber den monumentalen Crash (ohne Trapscreen) hattest du schon mit 10.238, oder?

Ja, so war's.

Aber lies bitte mal meinen Nachtrag in meinem obigen Post. Kurz gesagt: Die Probleme liessen sich heute *nicht* wiederholen. Per heute gilt: Alles bestens mit der 10.238.

Danke für alles!

Gruß,
Lutz W.

[DonLucio]

Wie gesagt, wenn du mir die descriptor Info geben könntest ...

Falls es für dich noch interessant ist (nachdem der Fehler offenbar verschwunden ist; aber man weiß ja nie ):
Gemäß der von dir verlinkten Rexx-Doku habe ich mal versucht, diesen Descriptor zu erfahren.

Problem ist dabei, dass der vorgesehene Weg, die Funktion RxUsbDeviceGetDescriptor(), ein Handle braucht, wie es von RxOpen() besorgt wird. RxOpen() aber verlangt bereits Device- und Vendor-Informationen, die ich nicht habe (nicht kenne). Ich habe mich also über die QueryDeviceReport-Funktion herangemacht, die mir die "concatenation of Device Descriptor and Configuration Descriptor" liefert. Da ich drei USB-Devices habe, kann ich dir jetzt als Ergebnis drei solcher compound-strings liefern (tatsächlich belegt ist bei mir z.Zt. nur 1 Device, aber welches??):

Code: Alles auswählen

Number of USB-Devices: 3
12010002000000086D0477C000720102000109022200010100A032090400000103010200092111010001222E000705810304000A

1201000200000040E30552073302030400010902200001010080310904000002080650000705810200020007050202000200

12010002000000402D15092500010102050109022000010104C0010904000002080650060705810200020007050202000200

Ehrlich gesagt, ich kann damit nix anfangen ... sieht mir auch nicht nach hexadezimal-dargestelltem Buchstaben-Zahlen-Salat aus.

Die drei Strings wurden mit diesem Rexx-Skript erzeugt:

Code: Alles auswählen

/* Rexx-Experimente mit USBCalls.dll	*/

rc = RxFuncAdd('UsbLoadFuncs','usbcalls','UsbLoadFuncs')
nok = ('' <> UsbLoadFuncs());

if \(nok) then do
   rc = RxUsbQueryNumberDevices(NumDev); say "Number of USB-Devices:" NumDev;
   do i = 1 to NumDev
      drop Report;	 /* muß jedesmal frisch gemacht werden */
      RC = RxUsbQueryDeviceReport( i, Report );
      if RC=0 then 
         say Report || "0A"x;
      else;
	 say "Fehler beim RxUsbQueryDeviceReport("i"), code="RC;
   end;
end;
else;
   say "Error registrating usbcalls";
exit;

Hilft uns das weiter ... ?

Gruß,
Lutz W.

[erdmann]

An sich kommt man so wie du vorgehst auch zum Ziel (du mußt nur wie gesagt "c2d" benutzen um die binären Daten in REXX lesbare zahlen zu wandeln).
Aber der erste Schritt wäre wie schon gesagt, USBRES.EXE oder "lsusb.exe" zu nehmen und die mal die devices mit ihren Vendor und Product IDs und den ganzen Descriptoren ausgeben zu lassen. Das kann man dann nämlich als Vorlage nehmen um ein bestimmtes device (mit Vendor und Product ID) auszuwählen und davon dann die descriptor info über REXX zu lesen.
Wenn ich die Info habe werde ich das REXX script schreiben und hier posten. Dann wird wahrscheinlich klar, wie's geht (wie gesagt, es ist nicht gerade "straight forward").

Nachtrag: ich sehe gerade, dass RxQueryDeviceReport in der Tat den Inhalt schon nach hexadezimalem String konvertiert (das ist bei den anderen Funktionen anders). Du müßtest also nur den String in Teile "schneiden" und mit "x2d" in Dezimalzahlen wandeln. Wo man schneidet sagt dir allerdings nur die USB spec ...

[erdmann]

Außerdem habe ich noch etwas "Suspektes" in USBMSD.ADD gefunden, bin mir aber nicht sicher ob das wirklich ein Fehler ist (der originale Code ist nicht von mir sondern von IBM). Ich könnte dir eine Testversion bauen, die du dir unter das Kopfkissen legen kannst (sprich: testhalber mal installieren und über einige Tage/Wochen beobachten).

[erdmann]

Und zuletzt: du solltest auf den AN Stack 12.07 upgraden, es wurden seit 12.04 eben noch eine ganze Reihe von Fehlern behoben.
Und wenn dann USBMSD.ADD immer noch nicht funktioniert: als bug bei AN melden. Du kannst dann darauf verweisen dass es mit meinem Stack 10.238 funktioniert (es muss also gehen). Du solltest dann auch das genaue USB device angeben welches du nutzt. Da brauchst du dann wieder die descriptor info, die dir USBRES.EXE bzw. lsusb.exe liefert.

[DonLucio]

Wo man schneidet sagt dir allerdings nur die USB spec ...

Und wo finde ich die ...? In den Rexx-Code-Snippets wird davon leider kein Gebrauch gemacht (dort wird nur der Returncode lesbar umgesetzt).

Aber egal: Mit Hilfe von usbres konnte ich jetzt - ohne viel Programmiererei - mein Gerät identifizieren. Es handelt sich um den Vendor "4 Either Hand", und die Produkt-Nummer 2509.

Aber ich denke, wir könen das Thema eigentlich abschließen, solange sich mit deinerm 10.238 diese Platte anständig verhält.

Vielleicht noch eine Frage zu meinem Verständnis:
Der Hersteller-Name ist anscheinend nicht direkt Bestandteil des Descriptors, sondern wird über die Vendor-ID aus einer anderen Quelle besorgt?
Jedenfalls kann ich in den gesamten 104 Bytes, die mir RxUsbQueryDeviceReport()-Funktion liefert, kein einziges lesbares Zeichen entdecken. Ich finde dort zwar die Produktnummer, die Revision und den Language-Code, aber kein einziges Alpha-Zeichen.

Gruß,
Lutz W.