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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
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 zu diesem Kommentar
Share on other sites

  • 3 weeks later...
  • 1 month later...

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.

Link zu diesem Kommentar
Share on other sites

  • 2 weeks later...

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

Link zu diesem Kommentar
Share on other sites

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?

Link zu diesem Kommentar
Share on other sites

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

Link zu diesem Kommentar
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.

Gast
Reply to this topic...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...