Jump to content

Master Brick über USB-HUB am PC - Kein Disconnect Callback beim Abziehen des USB-Hubs?


Recommended Posts

Hallo,

mit folgendem Aufbau lässt sich ein Problem reproduzieren, dass ich erst kürzlich entdeckt habe:

Ein Master Brick ist über einen USB2.0-Hub mit der USB-Schnittstelle eines PCs verbunden:

PC  <--> USB2.0-HUB   <-->  Master Brick (FW 2.4.10)  

Verwendet wird der Versionsstand Brick Deamon V2.4.3 und Brick Viewer V2.4.16. Im Brick Viewer wird eine Verbindung hergestellt und es erscheint ein Reiter "Master Brick 2.1".

a) Wenn man nun die USB-Verbindung zwischen Master Brick und USB-Hub trennt, dann verschwindet im Brick Viewer der Reiter "Master Brick 2.1" automatisch. Nach erneutem Anstecken des USB-Kabels an den USB-Hub taucht der Reiter "Master Brick 2.1" automatisch wieder auf - so wie es sein soll.

b) Wenn man die Verbindung zwischen PC und USB-Hub trennt, wird dies vom Brick Viewer (in den allermeisten Fällen) nicht erkannt. Der Reiter "Master Brick 2.1" bleibt bestehen. Alle set-Funktionen können ohne Fehlermeldung ausgeführt werden, obwohl der Brick gar nicht mehr angeschlossen ist! Nach erneutem Anstecken des USB-Hubs (inkl. Master Brick) an den PC wird zwar ein Connect-Callback/Enumerate ausgelöst, sodass der Master Brick dann auch wieder weiter läuft, aber die Trennung sollte ja auch erkannt werden.

Woran könnte es liegen, dass die verlorengegangene USB-Verbindung zum Brick nicht erkannt wird, wenn man einen dazwischengeschalteten USB-Hub mit abtrennt?   

 

 

   

Link to post
Share on other sites

Linux, Windows oder macOS?

Brick Daemon verwendet die USB Hotplug Erkennung des Betriebssystems. Ich fürchte da können wir nicht viel machen, wenn das nicht richtig funktioniert.

Link to post
Share on other sites

Dann zeichne bitte mal mit dem Log Viewer den Fehlerfall auf. Dazu folgende Schritte durchführen:

  1. Hub ist abgesteckt
  2. "Brickd 2.4.3 - Log Viewer" starten
  3. "Live Log" auf "Debug Level" stellen
  4. Hub anstecken, kurz warten und wieder abstecken. Falls das Problem nicht aufgetreten ist, dann Log Viewer schließen und bei 1. wieder beginnen. Log Viewer fehlt noch eine Clear Funktion, daher muss Log Viewer neugestartet werden. Bitte nur einen An- und Absteckvorgang aufzeichnen
  5. Live Log mittels "Save..." speichern und hier anhängen

 

Link to post
Share on other sites

Ich das jetzt mal so gemacht - allerdings noch mit parallel geöffnetem Brick Viewer, um sehen zu können, ob ich so einen Fehlerfall erwische. Zu folgenden Zeitpunkten habe ich Aktionen durchgeführt (vgl. Anhang):

13:26:30 - Klick auf "Connect" im Brick Viewer

13:26:40 - USB-Hub angesteckt

13:26:50 - USB-Hub abgesteckt

13:27:00 - Klick auf "Disconnect" im Brick Viewer

Man kann erkennen, dass die Trennung vom Master Brick [6rkehm] eigentlich erkannt wurde? Im Brick Viewer blieb der Reiter "Master Brick 2.1" nach 13:26:50 aber offen... 

 

brickd_live_20210114_132710.log

Link to post
Share on other sites

Okay, das war sehr hilfreich. Das ist ein Bug in brickd.

Brickd erwartet, dass zwischen dem Abstecken und der Benachrichtigung vom OS dazu maximal eine Sekunde vergeht. Im ersten Log vergehen dazwischen aber 2,5 Sekunden. Im zweiten fehlerfreien Log vergeht nicht mal 1 Millisekunde dazwischen.

Der Bug ist, dass brickd das Abstecken dann nicht richtig behandelt und dadurch der Enumerate-Disconnected Callback nicht gesendet wird. Dadurch bleibt der Tab in Brick Viewer stehen.

Ich werde hier in Kürze eine korrigierte brickd Version zum Testen posten.

Link to post
Share on other sites
  • 4 weeks later...
  • 1 month later...

Danke!

Ich habe die Version heute gleich ausprobiert. Das Abziehen des USB-Hubs wird nun immer erkannt. Allerdings sind dann beim Testen sporadisch andere Fehler aufgetreten, die ich mir nicht richtig erklären bzw. nicht reproduzieren konnte. Wie ich nun gemerkt habe, ist das wohl zum Teil auf einen Wackelkontakt am USB-Stecker zurückzuführen (zu viele Steckzyklen 🙄).

Im Anhang ist aber ein Protokoll von einem Fehlerfall, der dazu führte, dass sich der Brick Daemon verabschiedet hat. Vielleicht findest Du Hinweise auf was das zurückzuführen sein könnte? Das kommt nur sehr selten vor, aber ich weiß in diesem auch Fall nicht, wie man den Daemon manuell wieder neu startet? Ich habe darauf hin den PC neu gestartet. (Zum Protokoll: Ich hatte da zwei separate Stapel zum Test wechselweise an- und abgesteckt - jeweils mit USB-Hub. Am USB Hub des 6rkehm-Masters waren hierbei noch andere USB-Geräte angeschlossen, u.a. FTDI RS232).brickd_live_20210316_160155.log

Link to post
Share on other sites

Ich habe gerade noch einen anderen Kunden beim dem brickd auch durch das USB Abziehen abzustürzen scheint. Ich bekomme es leider nicht hin das Problem hier zu reproduzieren.

Kann ich dir zumuten eine spezielle brickd Version (die ich noch erstellen muss) in einem Debugger (z.B. GDB) laufen zu lassen, um einen Backtrace des Crashes zu bekommen?

Link to post
Share on other sites

So, jetzt endlich!

Zuerst den installieren Brick Daemon Dienst stoppen. Das kannst du über den Windows Dienste Manager oder den Brick Daemon Log Viewer tun.

Dann die angehängte brickd.exe herunterladen. Ich habe sie unter C:\Users\photron\Downloads\brickd.exe gespeichert.

Jetzt GDB installieren. Dazu lädst du dir mingw-w64-install.exe herunter. Auf der folgenden Seite dem Sourceforge Link folgen, der Download startet automatisch:

http://mingw-w64.org/doku.php/download/mingw-builds

Das dann mit den Standardeinstellungen installieren.

Darauf hin findest du unter C:\Programme (x86)\mingw-w64 ein Verzeichnis mit kryptischen Namen, in meinem Fall i686-8.1.0-posix-dwarf-rt_v6-rev0. Darin wiederum ist eine mingw-w64.bat Datei. Diese starten. Darauf hin öffnen sind eine Kommandozeile.

Jetzt GDB mit brickd.exe starten (angepasst auf den Pfad an dem du brickd.exe gespeichert hast):

gdb --args "C:\Users\photron\Downloads\brickd.exe" --console

GDB hat jetzt brickd.exe geladen, aber noch nicht gestartet. Dazu "r" eingeben (ohne Anführungszeichen) und Enter drücken. Brick Daemon sollte starten und Logmeldungen ausgeben.

Jetzt das Problem erzeugen und brickd abstürzen lassen. GDB sollte den Absturz abfangen und unten links sollte (gdb) stehen. Dort jetzt "bt full" eingeben (ohne Anführungszeichen) und Enter drücken. Darauf hin gibt GDB länglich aus wo der Absturz passiert ist und wie das Programm zu dieser Stelle bekommen ist. Die gesamte Ausgabe des bt full Befehls bitte hier posten.

brickd.exe

Link to post
Share on other sites
  • 2 weeks later...

Im Anhang nun mal ein GDB Absturzprotokoll. 

Was in diesem Fall passiert ist: Ich habe manchmal ein Problem mit der USB-Verbindung an sich. Es kann vorkommen, dass sich die USB-Geräte (also HUB mit Master) nach dem Anstecken an den PC zyklisch an- und abmelden. Das wiederholt sich dann beliebig oft ohne äußeres Zutun. Im Win10 Gerätemanager baut sich dann der Gerätebaum ca. alle 2-3 Sekunden neu auf und auch in der Windows-Startleiste rechts unten "blinkt" das USB-Symbol für ein neu erkanntes Gerät mit der selben Frequenz auf...
Ich habe noch nicht herausgefunden, ob die Ursache hard- oder softwareseitig zu suchen ist (schlechte USB-Steckerverbindung oder doch eher Firmware-/Treiber-/Windows-Problem etc.?). Jedenfalls scheint in diesem besonderen Fehlerszenario der brickd laut den GDB-Ausgaben etwas "hinterherzuhinken". D.h. er bekommt die vielen "hochfrequenten" An- und Abmeldevorgänge nicht in vollständiger Anzahl sondern nur sporadisch mit. Vielleicht erfolgen dadurch Zugriffsversuche auf schon wieder nicht mehr vorhandene Geräte?

gdb_bt_full_2021_04_09.txt

Link to post
Share on other sites

Laut Log wurde der Master Brick getrennt, brickd versucht die offenen USB Read Transfers abzubrechen. Das klappt aber nicht, da libusb behauptet diese nicht mehr zu kennen. Dann versucht brickd den libusb Handle für den Master Brick zu schließen. Intern läuft libusb dann über die Liste der offenen USB Transfers für den Master Brick und crasht dabei.

Auch wenn die USB Geräte schnell auftauchen und wieder verschwinden sollte daran brickd bzw libusb nicht crashen. Ich befürchte fast, dass das ein alter Bug in libusb ist. Brick Daemon für Windows kommt aktuell mit einer 2 Jahre alten libusb Version. In der Zwischenzeit ist viel im Inneren von libusb passiert. Ich denke ich muss mal die ganzen libusb Altlasten aus brickd loswerden, allgemein die libusb Version erhöhen und unter Windows eine aktuelle libusb Version ausliefern.

Kannst du diesen "Wackelkontakt" noch einen Moment nicht beheben? Ich würde dir gerne noch eine weitere brickd Version zum Testen geben mit aktueller libusb, um zu sehen, ob das dass Problem behebt. Wenn ich das schnell hinbekommen, vielleicht sogar noch heute.

Link to post
Share on other sites
  • 3 weeks later...

@ts555 So jetzt aber. Es war komplizierter als gedacht auf die neuste libusb Version zu aktualisieren. Teste bitte diese brickd.exe genau so wie die letzt, um zu sehen ob der Crash noch auftritt. Falls ja zeichne bitte wieder einen Backtrace mit GDB auf.

brickd.exe

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...