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

[ts555]

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?   

 

 

   

[photron]

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.

[ts555]

Windows 10

Im Windows-Gerätemanager wird beim An-/Abstecken alles fehlerfrei an- und abgemeldet...

 

[photron]

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

 

[ts555]

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

[ts555]

Hier zum Vergleich noch ein Log zu einem erfolgreichen Trennvorgang (trotz USB-Hub). 
Wieder mit Zeitangaben:

14:05:50 - Klick auf "Connect" im Brick Viewer

14:06:00 - USB-Hub angesteckt

14:06:10 - USB-Hub abgesteckt

14:06:20 - Klick auf "Disconnect" im Brick Viewer

 

brickd_live_20210114_140805.log

[photron]

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.

[ts555]

Ja wäre super, wenn das verbessert werden könnte 👍

[ts555]

Hallo photron,

hattest Du schon Zeit, Dich dem brickd zu widmen - bzgl. dem Enumerate-Disconnect Callback Thema?

[photron]

Sorry, bisher nicht. Aktuell ist hier alles auf Wallboxen fokussiert.

[photron]

@ts555 Sorry, das hat eine Weile gedauert, aber hier ist jetzt endlich eine brickd Testversion, die das Problem beheben sollte.

brickd_windows_2_4_3_snapshot_b046504.exe

[ts555]

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

[photron]

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?

[ts555]

Mit GDB habe ich noch keine Erfahrung. Aber ich kann das gerne versuchen...

[photron]

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

[ts555]

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

[photron]

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.

[ts555]

Ja ich kann das gerne nochmal testen.

[photron]

@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

[ts555]

Nachdem ich die letzten Wochen leider keine Zeit hatte, kann ich die neue Version von heute an nun endlich testen. Bei der neuen Version werden folgende Meldungen ausgegeben; Verbindung zu TF-Mastern wird nicht hergestellt:

 

bearbeitet June 25, 2021 at 07:35 von ts555

[photron]

Dass libusbK und UsbDk fehlen ist normal und erwartet.

Der normale Brick Daemon findet aber die Bricks? Das keine Bricks gefunden werden liegt an diesem speziellen Brick Daemon, oder?

Starte brickd bitte mit Debug Logging (--debug). Da das viel Ausgabe erzeugt solltest du das direkt in eine Datei schreiben lassen (--log-to-file <pfad-zur-datei>).

brickd.exe --console --debug --log-to-file brickd-debug.log

Nach dem Start 10 Sekunden laufen lassen, dann mit Ctrl+C beenden und die brickd-debug.log Datei hier anhängen.

[ts555]

Habe es nochmal probiert. Jetzt funktioniert es. Ich weiß nicht, was beim letzten mal passiert ist...

Ich hatte jetzt sogleich wieder einen Fall, wo sich die Bricks (ohne äußeres Zutun) zyklisch an- und abgemeldet haben. So wie es aussieht führt dies nun aber nicht mehr zum Absturz des neuen brickd. Im Anhang eine Kopie der Konsolenausgabe. brickd-debug.log

Hast Du eine Idee, was die Ursache für die Fehlermeldungen sein könnte (invalid response packet/invalid UID)?

console.txt

[photron]

Die Bytefolge 00 00 00 00 0A E6 08 00 00 00 ist an sich erstmal ein fast gültiges Packet. Das könnte ein interne Enumerate Connected Request sein, das aber nie über USB raus geht. Die Bytefolge hat allerdings das Längenbyte auf 0A statt 08 stehen. Ich kann dir nicht erklären warum das passiert.

Gegenfrage: Das Auftauchen und Verschwinden der Bricks an USB und diese ungültigen Packets tauchen alle nur in Verbindung mit dem USB Hub auf, oder?

Funktioniert der Stack denn, abgesehen von der Invalid-UID Meldung?

[ts555]

Das Auftauchen und Verschwinden der Bricks an USB ist bisher nur in Verbindung mit USB-Hubs aufgetreten. Ob die Meldung bzgl. ungültigem Paket auch ohne USB-Hub auftritt habe ich noch nicht getestet.

Der Stack funktioniert trotz Invalid-UID Meldung.

Ich glaube ich habe tatsächlich ein Problem mit meiner USB-(Steck)verbindung. Anbei ein kurzes Protokoll von heute.
- Minute 42: brickd gestartet, Stack läuft
- Minute 46: Verbindung zum Stack plötzlich getrennt (ohne äußeres Zutun)
- Minute 48: USB-Stecker am Laptop minimal bewegt -> Stack wieder verbunden! (allerdings fehlt Master auf Pos 2)
- Minute 51: Stack-Reset manuell ausgelöst -> Stack komplett wieder verfügbar

Bei Gelegenheit sollte ich vielleicht mal die USB D+ und D- Signale mit dem Oszi monitoren, die am Stack bzw. USB-Hub ankommen...  

Aber entscheidend ist ja: Der neue brickd ist bisher nicht mehr abgestürzt. Werde den die nächsten Tage/Wochen mit GDB weiter testen.
 

console 06-07-2021.txt

[photron]

Die wenigsten USB Hubs sind wirklich gut. Die meisten haben irgendwelche Probleme.

Ich hätte auch die USB Kabel selbst in Verdacht. Ich habe hier im Laufe der Firmengeschichte son mehrere USB Kabel auf der A und der Mini B Seite ausgenudelt.