[geloest] Masterbrick haengt sich weg (Flash/Reset/Re-connect)

[Loetkolben]

Mache ich nun ein neues Thema auf oder stecke ich mein Problem hier rein? ... Also hier. 

 

Ich habe remote das IO4 Bricklet (edit: von 1.1.1) auf 1.1.2 geflasht.

 

Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0

 

Das Flashen hat im Prinzip funktioniert. Nun noch einen Reset im Brickv, damit auch die aktuelle FW aktiv wird. SOFORT mit Brickv Disconnect und Connect hinterher. Nochmals Disconnect und Connect zum testen. Schwups und da war der Master "weg". Er ist nicht mehr erreichbar. 

 

Das ist nicht das erste mal gewesen, dass der Masterbrick einen (schnellen) Reconnect nicht ueberlebt hat.

 

Kann das zeitlich mit der WLAN Firmware zu tun haben? Dieser Stack hat zwar kein WLAN, macht aber seit einiger Zeit Probleme. Vielleicht ist auch der Reset selbst nicht schuld daran, sondern der Zugriff via LAN mit dem Brickv.

Ich kann mich daran erinnern, dass ich mich 4-5 mal mit dem Brickv in kurzen Abstaenden (ca. alle 2-3 Sekunden) zum Brickd verbunden habe und danach war die Kommunikation weg.

 

In den alten Versionen hat es bei solchen Spielereien keine Probleme gegeben.

 

Ist der Masterbrick nach einem Reset oder Disconnect vielleicht noch nicht richtig bereit einen neuen Connect anzunehmen?

 

Featurerequest: Koennte der Brickv nicht automatisch einen Disconnect machen wenn man den Resetbutton drueckt? Gibt es evtl. dadurch Probleme?

 

Der Loetkolben

[photron]

Ich spalte das hier mal in einen neuen Thread ab.

[photron]

Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0

 

Welche brickd Version ist das?

 

Das Falshen hat im Prinzip funktioniert. Nun noch einen Reset im Brickv, damit auch die aktuelle FW aktiv wird. SOFORT mit Brickv Disconnect und Connect hinterher. Nochmals Disconnect und Connect zum testen. Schwups und da war der Master "weg". Er ist nicht mehr erreichbar. 

 

Warum reconnectest du hier? Das ist ja hier nicht notwendig. Die Verbindung um die es da geht, ist die TCP/IP Verbindung zu brickd, nicht die USB Verbindung von brickd zum Master Brick.

 

Hab das hier gerade nachgestellt und es funktioniert wie erwartet.

 

Und was meinst du mit "weg"? Wird der Brick nicht mehr in brickv angezeigt? Wenn du erneut reconnectest taucht er dann wieder auf? Gibt es eine Exception in brickv? Kennt lsusb ihn noch? Was sagt das brickd Log dazu?

 

Das ist nicht das erste mal gewesen, dass der Masterbrick einen (schnellen) Reconnect nicht ueberlebt hat.

 

Beim Connect broadcastet brickv einen Enumerate Request an alle und dann noch ein GetStackID an alle Devices die Enumerate aufzählt. Ich sehe nicht warum das ein Problem wie das hier erzeugen sollte.

 

Ich kann mich daran erinnern, dass ich mich 4-5 mal mit dem Brickv in kurzen Abstaenden (ca. alle 2-3 Sekunden) zum Brickd verbunden habe und danach war die Kommunikation weg.

 

Welche Kommunikation?

 

In den alten Versionen hat es bei solchen Spielereien keine Probleme gegeben.

 

Welche Versionen? Firmware, brickd oder brickv?

 

Ist der Masterbrick nach einem Reset oder Disconnect vielleicht noch nicht richtig bereit einen neuen Connect anzunehmen?

 

Reset und (Dis)connect sind zwei sehr verschiedene dinge für einen Brick. Der Brick an sich hat mit dem (Dis)connect zu brickd nichts zu tun!

 

Featurerequest: Koennte der Brickv nicht automatisch einen Disconnect machen wenn man den Resetbutton drueckt?

 

Nein, da das nichts mit einander zu tun hat und das auch nicht sinnvoll ist im Allgemeinen.

[photron]

Okay, ignoriere erstmal alles was ich da noch gerade gefragt habe und beantworte mir die nächste Frage zu erst.

 

Debian -- Brickv.1.1.13 -- LAN -- Debian -- Brickd -- USB -- Master1.4.0

 

Hast du in diesem Aufbau noch ein weiteres Programm neben brickv, dass gleichzeitig mit brickd verbunden ist und mit enumerate arbeitet?

[Loetkolben]

Hast du in diesem Aufbau noch ein weiteres Programm neben brickv, dass gleichzeitig mit brickd verbunden ist und mit enumerate arbeitet?

 

Antwort zwischendurch. Nein. Es kann sein, dass von einem Server ausserhalb die Sensoren per Cron (TCP/netcat) abgefragt werden. Alle 10 Minuten ein Request, also kein Dauerrequest. Ein Enumerate wird nicht durchgefuehrt.

 

Kommt da eine Nachtigall?

 

Der Loetkolben

[Loetkolben]

Welche brickd Version ist das?

#dpkg -l |grep brickd

ii  brickd  1.0.9  Brick Daemon

 

Warum reconnectest du hier? Das ist ja hier nicht notwendig. Die Verbindung um die es da geht, ist die TCP/IP Verbindung zu brickd, nicht die USB Verbindung von brickd zum Master Brick.

 

Damit ich sehen kann ob das Bricklet wirklich die neue FW hat. Hmm lass mich mal ueberlegen. ...

Wuerde nach einem flashen des Bricklets der Brickviewer die neuen Firmwarestaende automatisch einlesen sobald sich der Masterbrick mit dem brickd wieder verbunden hat? Ne, oder?

 

Und was meinst du mit "weg"? Wird der Brick nicht mehr in brickv angezeigt? Wenn du erneut reconnectest taucht er dann wieder auf? Gibt es eine Exception in brickv? Kennt lsusb ihn noch?

 

Weg = Nicht mehr erreichbar. Der Button "Connect" im Brickv wechselt noch auf "Disconnect" aber es erscheinen keine Reiter mehr. Das geht auch jetzt noch. Der Brickv hat keine Fehlermeldungen gezeigt.

 

lsusb hatte das Brick noch angezeigt, aber als ich dann mit dem Tool "usbreset" auf das Geraet zugegriffen habe kam schon ein "Device not found" zurueck. Bei einem erneuten lsusb war es dann auch nicht mehr zu sehen. Selbst nach einem Reboot ist kein Masterbrick zu sehen.

 

Was sagt das brickd Log dazu?

 

Komplettes brickd.log. Es ist kein Debugging eingeschaltet.

Wenn ich das richtig sehe kommen diese Meldungen und vom reboot der Maschine als der brickd versuchte sich zum Brick zu connecten. Ein "/etc/init.d/brickd start" erzeugen die gleichen Meldungen nochmal.

 

Traceback (most recent call last):
  File "/usr/share/brickd/brickd_linux.py", line 157, in <module>
    brickd.daemonize()
  File "/usr/share/brickd/brickd_linux.py", line 145, in daemonize
    self.start()
  File "/usr/share/brickd/brickd_linux.py", line 85, in start
    reactor.listenTCP(config.PORT, BrickProtocolFactory())
  File "/usr/lib/python2.6/dist-packages/twisted/internet/posixbase.py", line 419, in listenTCP
    p.startListening()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 855, in startListening
    raise CannotListenError, (self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:4223: [Errno 98] Address already in use.

 

Ich kann mich daran erinnern, dass ich mich 4-5 mal mit dem Brickv in kurzen Abstaenden (ca. alle 2-3 Sekunden) zum Brickd verbunden habe und danach war die Kommunikation weg.

 

Welche Kommunikation?

 

Brickviewer mit dem Masterbrick. Also genauso wie beschrieben.

 

In den alten Versionen hat es bei solchen Spielereien keine Probleme gegeben.

 

Welche Versionen? Firmware, brickd oder brickv?

 

Masterbrick 1.1.7 mit brickd 1.0.0?

 

Featurerequest: Koennte der Brickv nicht automatisch einen Disconnect machen wenn man den Resetbutton drueckt?

 

Nein, da das nichts mit einander zu tun hat und das auch nicht sinnvoll ist im Allgemeinen.

 

OK, dann aber nochmals die Frage: Wird die geflashte Firmwareversion im Brickviewer nach dem Flashen und dem Reset automatisch angezeigt ohne sich neu connecten zu muessen?

 

Da der Rechner bei mir ist, kann ich nachher wieder mal "Reset" druecken. 

 

 

Der Loetkolben

[photron]

Hast du in diesem Aufbau noch ein weiteres Programm neben brickv, dass gleichzeitig mit brickd verbunden ist und mit enumerate arbeitet?

 

Antwort zwischendurch. Nein. Es kann sein, dass von einem Server ausserhalb die Sensoren per Cron (TCP/netcat) abgefragt werden. Alle 10 Minuten ein Request, also kein Dauerrequest. Ein Enumerate wird nicht durchgefuehrt.

 

Okay, ich hätte jetzt gehofft du hättest genau das Problem das ich im Rahmen der Vorbereitung für die Elektor Live gefunden und behoben habe. Das Problem war das wenn 2 Clients/Bindings recht zeitgleich ein GetStackID für das gleiche Device ausgeführt haben, dass ihre intern Datenhaltung dann durcheinander geraten ist. Da GetStackID ein Braodcast ist wird auch die Antwort an alle geschickt und beide Clients bekommen die Antwort zweimal. Das kann dann u.a. dazu führen, dass der Brick in brickv nicht angezeigt wird, da brickv dadurch beim Aufzählen des Bricks eine Exception bekommt.

 

Dieser gleichzeitige Aufruf von GetStackID für das gleiche Device kommt typischerweise durch die Verwendung von Enumerate zustande. Da das bei dir aber nicht der Fall ist und du auch nicht von 2 Clients GetStackID aufrufst hast du noch ein anderes Problem

 

Erinnert mich daran, dass ich die korrigierte brickd Version releasen sollte. Kommt morgen

[photron]

Warum reconnectest du hier? Das ist ja hier nicht notwendig. Die Verbindung um die es da geht, ist die TCP/IP Verbindung zu brickd, nicht die USB Verbindung von brickd zum Master Brick.

 

Damit ich sehen kann ob das Bricklet wirklich die neue FW hat. Hmm lass mich mal ueberlegen. ...

Wuerde nach einem flashen des Bricklets der Brickviewer die neuen Firmwarestaende automatisch einlesen sobald sich der Masterbrick mit dem brickd wieder verbunden hat? Ne, oder?

 

Doch genau so passiert das.

 

Wenn du den Brick durch den Reset Knopf in brickv, oder per Reset Knopf auf dem Brick selbst oder durch Ab- und Anstecken des USB Kabels neustartet, dann sieht das für brickd und brickv immer gleich aus.

 

Der Brick verschwindet als USB Device und taucht dann kurze Zeit später wieder als USB Device auf. brickd weiss nicht, dass das der gleiche Brick ist und das braucht er auch nicht. brickd und brickv cachen da nichts. brickv bekommt das Reset/Abstecken durch ein enumerate mit is_new=false mit und das Neuauftauchen als enumerate mit is_new=true. Dann liest brickv auch die Versionsinformationen neu aus.

 

Das heißt in deinem Fall reicht ein Reset des Bricks aus. Du musst nicht neu zu brickd verbinden.

 

Dennoch würde ich gerade dein Reconnect Problem verstehen und beheben. Nur ist mir hier gar nicht klar wie ein Reconnect zu brickd dazu führt, dass der Brick auf USB Ebene ein Problem hat und verschwindet.

 

Was sagt das brickd Log dazu?

 

Komplettes brickd.log. Es ist kein Debugging eingeschaltet.

Wenn ich das richtig sehe kommen diese Meldungen und vom reboot der Maschine als der brickd versuchte sich zum Brick zu connecten. Ein "/etc/init.d/brickd start" erzeugen die gleichen Meldungen nochmal.

 

Traceback (most recent call last):
  File "/usr/share/brickd/brickd_linux.py", line 157, in <module>
    brickd.daemonize()
  File "/usr/share/brickd/brickd_linux.py", line 145, in daemonize
    self.start()
  File "/usr/share/brickd/brickd_linux.py", line 85, in start
    reactor.listenTCP(config.PORT, BrickProtocolFactory())
  File "/usr/lib/python2.6/dist-packages/twisted/internet/posixbase.py", line 419, in listenTCP
    p.startListening()
  File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 855, in startListening
    raise CannotListenError, (self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:4223: [Errno 98] Address already in use.

 

Nein, das hat nichts mit dem Brick oder USB zu tun. Das Problem hier ist das brickd versucht den TCP/IP Socket auf Port 4223 zu öffnen und jemand auf diesem Port schon einen Socket offen hat. Wahrscheinlich läuft schon ein brickd und du versuchst noch einen zu starten?

[Loetkolben]

Hallo photron,

 

danke erstmal fuer die Unterstuetzung. Ich versuche das Problem weiter einzugrenzen. Es kommt nur vor wenn man "spielt". Also Firmware updatedet, Resets ausfuehrt oder mit dem Brickv spielt. Im normalen Betrieb ist dieser Stack ganz artig. 

 

Durch Deine Antworten komme ich zu folgender Zusatzfrage:

Muss ich nach einem Reset des Masterbricks, bevor ich einen Temperaturwert per TCP/netcat abhole, ein "Enumerate" an den Stack schicken oder macht der das intern schon alleine direkt nach dem Reset?

Ich denke nein, da die Bricklets gleich bleiben und der Masterbrick nach einem Reset seine Zuordnungen hoffentlich wieder selbst aufbaut. 

 

Der Loetkolben

[photron]

Muss ich nach einem Reset des Masterbricks, bevor ich einen Temperaturwert per TCP/netcat abhole, ein "Enumerate" an den Stack schicken oder macht der das intern schon alleine direkt nach dem Reset?

 

Nein, die Bricks erkennen beim Neustart was wo angeschlossen ist.

 

Das einzige was es in diese Richtung gibt ist, das brickd standardmäßig nicht Callbacks an alle verbundenen IP Connections weiter gibt, sondern nur an die die vorher GetStackID aufgerufen haben, dies passiert aber automatisch in allen Bindings. Das betrifft dich hier aber nicht und das wird auch mit Protokoll Version 2 anders, da wird da brickd und das Protokoll an sich stateless machen werden so dass es robuster wird.

[Loetkolben]

Der Brick verschwindet als USB Device und taucht dann kurze Zeit später wieder als USB Device auf. brickd weiss nicht, dass das der gleiche Brick ist und das braucht er auch nicht. brickd und brickv cachen da nichts. brickv bekommt das Reset/Abstecken durch ein enumerate mit is_new=false mit und das Neuauftauchen als enumerate mit is_new=true. Dann liest brickv auch die Versionsinformationen neu aus.

 

Das heißt in deinem Fall reicht ein Reset des Bricks aus. Du musst nicht neu zu brickd verbinden.

 

Och.  Entschuldigung, aber da waere ich nicht drauf gekommen. Was haelst du von einer Messagebox die nach dem Resetknopf druecken erscheint und kurz erklaert, dass sich der Brick gleich wieder meldet und der Brickviewer die Werte dann automatisch neu einliest und das im Viewer anzeigt?

 

 

-->>> brickd Bug. Erklaerung ab hier:

 

Nein, das hat nichts mit dem Brick oder USB zu tun. Das Problem hier ist das brickd versucht den TCP/IP Socket auf Port 4223 zu öffnen und jemand auf diesem Port schon einen Socket offen hat. Wahrscheinlich läuft schon ein brickd und du versuchst noch einen zu starten?

 

Da hast du Recht. Das mit dem Port hat mich auch stuzig gemacht und ich habe gerade ein wenig geprueft und einen Nebenkriegschauplatz gefunden. Der brickd fuehrt uns hier hinters Licht. Siehe hier:

 

#reboot

~~~ Pause ~~~

#uptime
up 2 min

#/etc/init.d/brickd start
Starting Brick Daemon: brickd.

#/etc/init.d/brickd stop
Stopping Brick Daemon: start-stop-daemon: warning: failed to kill 1039: No such process

#ls -l /var/log/brickd.log
-rw-rw-rw- 1 root root 710 25. Okt 19:05 /var/log/brickd.log #Mit bekanntem Inhalt.

 

und nun Du? 

Das Problem erkennen wir beide! Nach dem Reboot ist bereits ein brickd gestartet worden. DUMMERWEISE kann man aber nochmals einen brickd starten. Hier mit der PID 1039. Der bricht aber ab (ohne das man es sieht), schreibt das Logfile und setzt noch die KILLPID auf 1039. Welche PID der brickd hat, der beim reboot gestartet wurde ist nicht bekannt. Ein "/etc/init.d/brickd stop" versucht nun PID 1039 zu stoppen. Diesen Prozess gibt es aber nicht. DESHALB habe ich das Logfile falsch interpretiert. Sorry.

 

# ps -ef|grep brickd
root       890     1  0 19:03 ?        00:00:01 python /usr/share/brickd/brickd_linux.py

 

Das ist der brickd mit der PID 890 der nach dem reboot automatisch gestartet wurde.

 

Deshalb: Bitte den brickd ueberpruefen lassen ob schon ein brickd laeuft und dann garnicht erst versuchen eine 2. Instanz zu starten die dann die KILLPID umsetzt. -> "brickd already running with PIDxxx"

 

Edit: Gerade installiert: Der brickd 1.0.10 verhaelt sich genauso.

 

Der Loetkolben

 

[Loetkolben]

So bin nun zu Hause.

Edit: Bitte erst den Beitrag unter diesem Beitrag lesen. Das Problem mit dem lokalen Windows PC besteht zwar noch, aber ich kann es noch nicht zuverlaessig reproduzieren.

 

Reset am Masterbrick und alles laeuft wieder.

 

Nun sitze ich am einem Windows PC, Masterbrick am Debian Rechner. Rufe den Brickv auf und mache einen Reset per brickv. Clicke munter bis lustig auf den Reitern rum. Die Antworten werden langsamer (Anzeige des neuen Reiters). Alles bleibt stabil.

Eine Minute spaeter das gleiche Spiel. Antwortzeiten werden langsamer. Einmal Disconnect-Connect mit Brickviewer und es kommt keine Antwort. "Weg ist er."

 

 

Nun mache ich ein Update der FW von 1.4.0 auf die aktuelle 1.4.5 am PC. Clicke munter auf den Reitern rum, nur die Antwortzeiten werden langsamer.

Masterbrick weg vom PC, wieder an dem Debian PC. Connect mit brickv und langsame Anzeige der Reiter. Ohha! Nun ein Disconnect und Connect. Siehe da, keine Verbindung. "Weg ist er."

 

Ein Resetbuttondruck am Masterbrick brachte alles wieder ins Lot.

 

Ich fasse mal zusammen:

 

Wenn der Masterbrick in einen Zustand kommt wo er nur langsam antwortet, sich dann der Brickv Disconnected und wieder Connected ist schluss mit der Kommunication.

 

Der instabile Zustand kann hervorgerufen werden durch wildes und buntes klicken auf die Reiter oder aber anscheinend nach einem Reset per Button. (Siehe ersten Beitrag des Threads)

 

Ich forsche weiter.

 

Der Loetkolben

EDIT: Nachdem ich den Beitrag hier drunter mit dem reproduzierbaren Ablauf erstellt habe frage ich micht, wie ich am lokalen PC es auch geschafft habe den Brick zum Absturz zu bringen, da hier keine Pakete von anderen Rechnern ankommen. Vielleicht haengt es aber auch nur mit dem Aufruf des IO4 Reiters zusammen.

 

 

 

 

[Loetkolben]

Ich glaube ich habe es! 

 

Hier ist es reproduzierbar. Kein wildes clicken notwendig.    Vorab schonmal die Konfiguration:

 

WindowsPC -- Brickv1.1.13 -- LAN -- Debian -- USB -- Masterbrick 1.4.5

+A_Temp 1.1.1

+B_Ambient 1.1.0

+C_Humidity 1.1.0

+D_IO4 1.1.2 Edit: Siehe Beitrag darunter

 

• Reset am Master druecken fuer einen definierten Zustand
   
  
• Brickv (am Windows PC) aufrufen und Connecten. Ggf. mal aufs Temperatur Bricklet gehen. Sonst nichts machen.
   
  
• Jetzt schickt der brickd PC "sich selbst" zu jeder vollen Minute ein Paket, so dass 3 LEDs am IO4 angehen.
  Ebenfalls schicken 3 Remote PCs zu vollen Minute plus 2 Sekunden, je ein TCP Paket, welches je eine LED am brickd PC wieder ausmacht. -> Rechnermonitoring mit 1-Bit Anzeige
  Anders ausgedrueckt: Der lokale PC macht 3 LED an und jeder entfernte Rechner "pustet" (s)eine LED nach ca. 2 Sekunden wieder aus. 
   
  
• Jetzt kommts:
  Wenn man nun nachdem alle 3 LED aus sind, auf den Reiter "IO4" clickt, geht von nun an alles nur noch zaeh weiter. Clicks auf die anderen Bricklet Reiter werden erst nach 4 Sekunden beantwortet. Evtl. ist hier schon "alles platt".
   
  
• Kaempft man sich zum Reiter Setup durch und Disconnected sich, ist ganz schluss! Ein Connect geht nicht mehr und man muss am Masterbrick den Resetknopf druecken.
   
  

Heisst wohl: Wenn sich nach Aufruf und Connect des Brickviewers die Konfig des IO4 durch TCP Pakete von einem dritten Rechner aendert und man dann den Reiter IO4 am Brickviewer anclickt ist schluss.

 

Kann das bitte mal jemand nachstellen? 

 

Ob nur das IO4 reicht oder ob die Portbelegung exact so sein muss erschliesst sich mir nicht.

Per "lsusb" ist das Brick noch zu sehen.

 

Der Loetkolben

[Loetkolben]

Weitere Erkenntnisse: Die IO4 Firmware 1.1.2 verursacht das Problem!

 

• Master downgrade auf 1.1.7, Rest Up to date (IO4 1.1.2): Absturz.
  
• Zusaetzlich IO4 downgrade auf 1.1.0, Rest nicht veraendert: Keine Abstuerze.
  
• Master wieder auf 1.4.5, IO4 auf 1.1.0 belassen, Rest nicht veraendert: Keine Abstuerze.
  

 

Es scheint also an der IO4 Firmware 1.1.2 (und wohl auch 1.1.1) zu liegen.

 

Der Loetkolben

 

Edit: PS: Hier koennte wieder das Thema Watchdog stehen.

Eine einfache "Voridee" habe ich aber noch: Koenntet ihr 1 oder 2 LED am Masterbrick "blinken" lassen. Von mir aus auch so: 10 Sek. aus - 0,5 Sek. an. Dann kann man wenigstens noch festellen ob der Masterbrick noch lebt und sich nur die Kommunikation verabschiedet hat oder ob "ganz Schluss" ist.

[borg]

Shit. Ich krieg zuviel. Wenn ich das richtig sehe tritt das Problem wieder nur auf Port B und D auf, sprich wir haben immernoch Probleme mit dem Compiler...

 

An der eigentlichen Funktionalität hat sich zwischen 1.1.0 und 1.1.2 ja auch gar nichts geändert.

 

Ich kümmer mich drum, im Zweifelsfall müssen wir runter auf die alte GCC Version. Sorry!

 

 

Edit: OK, wenn ich die Brick Context Größe auf 256 stelle (anstatt 250) ist das Problem definitiv behoben. Ich denke das ist der Weg den wir gehen sollten. D.h. es wird neue Brick Firmwares geben. Wenn ich da jetzt anfange und irgendwo NOPs einbaue um das Problem zu beheben funktioniert auf einmal etwas anderes nicht mehr... Das hat gar keinen Zweck.

[AuronX]

@borg: Habe ich das richtig verstanden, dass das Bricks und bricklets zueinander inkompatibel machen würde (also 250er zu 256ern)?

Falls ja würde ich das unter allen Umständen auf die Protokolländerung verschieben und das Problem bis dahin durch ein Compilerdowngrade beheben (wenn das hilft). Sonst habt ihr kurz hintereinander zwei inkompatible FW-Updates, obwohl eines (das beide inkompatibilitäten mitbringt) reichen würde.

 

Falls alles kompatibel bleibt ignoriert was ich geschrieben habe.

[borg]

Bleibt alles kompatibel. Einzig die IO4 Bricklet Firmware 1.1.2 wird nicht mit den älteren Brick Firmwares funktionieren.

[AuronX]

Das meinte ich doch

Ist ja auch nur meine Meinung, aber an eurer Stelle würde ich den alten Compiler nehmen wenn das hilft und keine anderen Schäden bringt (ist ja nur für ein paar Monate)

 

edit: Wie inkompatibel ist das eigentlich? Also was passiert wenn ich es trotzdem tun würde?

[borg]

Das meinte ich doch

Ist ja auch nur meine Meinung, aber an eurer Stelle würde ich den alten Compiler nehmen wenn das hilft und keine anderen Schäden bringt (ist ja nur für ein paar Monate)

Wir können überhaupt nicht einschätzen wann/wo/wie GCC diesen Alignment Fehler einbaut. Ich befürchte die Bricklet Context Größe zu fixen ist die einzige vernünftige Alternative. Wer bisher noch keine Probleme damit hatte oder die IO4 nicht an Port B oder D anschließt muss ja auch nicht updaten .

 

 

@Loetkolben: Kannst du nochmal mit der neuen Master Version probieren?

[macdiverone]

Mit dem Barometer und WLAN kannst du das auch beliebig provozieren.

 

Erst wird die Updatefrequenz im brickv gaaaaanz langsam und dann ist

 

_________________________________________________________ aus… :-/

 

 

[Loetkolben]

@Loetkolben: Kannst du nochmal mit der neuen Master Version probieren?

 

Muss mich kurz halten im Moment:

 

Master auf 1.4.6 und IO4 auf 1.1.2 geflasht. Rest so gelassen. Kurzer Test und scheint zu laufen. 

 

Was passiert wenn ich dem Master auf 1.4.6 bringe, aber das IO4 auf 1.1.0 lasse habe ich nicht probiert. Also weiss ich nicht wieweit die neue Master FW "kompatibel" mit der alten IO4 FW ist.

Ich krieg zuviel. Wenn ich das richtig sehe tritt das Problem wieder nur auf Port B und D auf, sprich wir haben immernoch Probleme mit dem Compiler...

Ist das wirklich das so? Ist das wirklich die gleiche Baustelle? Ich kann aus zeitlichen Gruenden heute nicht testen ob es wirklich nur an Port D und B das Problem gibt. Kann das jemand mal gegenpruefen?

 

Danke und viel Erfolg beim umschiffen!

 

@macdiverone

Was muss man genau bei dir machen um das Problem nachzustellen?

 

Der Loetkolben

[photron]

Mit dem Barometer und WLAN kannst du das auch beliebig provozieren.

 

Erst wird die Updatefrequenz im brickv gaaaaanz langsam und dann ist

 

_________________________________________________________ aus… :-/

 

Also Master Brick (Firmware 1.4.6) mit WIFI Extension, Barometer Bricklet (Plugin 1.1.2) versorgt über Step-Down Power Supply. Mit brickv darauf verbunden und seit 1,5 Stunden den Barometer Tab offen und es funktioniert einwandfrei.

 

Tust du da noch was anderes? Verwendest du andere Firmwareversionen?

 

Nachtrag: Barometer Bricklet Plugin Version auf 1.1.2 korrigiert.

[photron]

Nein, das hat nichts mit dem Brick oder USB zu tun. Das Problem hier ist das brickd versucht den TCP/IP Socket auf Port 4223 zu öffnen und jemand auf diesem Port schon einen Socket offen hat. Wahrscheinlich läuft schon ein brickd und du versuchst noch einen zu starten?

 

Da hast du Recht. Das mit dem Port hat mich auch stuzig gemacht und ich habe gerade ein wenig geprueft und einen Nebenkriegschauplatz gefunden. Der brickd fuehrt uns hier hinters Licht. Siehe hier:

 

#reboot

~~~ Pause ~~~

#uptime
up 2 min

#/etc/init.d/brickd start
Starting Brick Daemon: brickd.

#/etc/init.d/brickd stop
Stopping Brick Daemon: start-stop-daemon: warning: failed to kill 1039: No such process

#ls -l /var/log/brickd.log
-rw-rw-rw- 1 root root 710 25. Okt 19:05 /var/log/brickd.log #Mit bekanntem Inhalt.

 

und nun Du? 

Das Problem erkennen wir beide! Nach dem Reboot ist bereits ein brickd gestartet worden. DUMMERWEISE kann man aber nochmals einen brickd starten. Hier mit der PID 1039. Der bricht aber ab (ohne das man es sieht), schreibt das Logfile und setzt noch die KILLPID auf 1039. Welche PID der brickd hat, der beim reboot gestartet wurde ist nicht bekannt. Ein "/etc/init.d/brickd stop" versucht nun PID 1039 zu stoppen. Diesen Prozess gibt es aber nicht. DESHALB habe ich das Logfile falsch interpretiert. Sorry.

 

# ps -ef|grep brickd
root       890     1  0 19:03 ?        00:00:01 python /usr/share/brickd/brickd_linux.py

 

Das ist der brickd mit der PID 890 der nach dem reboot automatisch gestartet wurde.

 

Deshalb: Bitte den brickd ueberpruefen lassen ob schon ein brickd laeuft und dann garnicht erst versuchen eine 2. Instanz zu starten die dann die KILLPID umsetzt. -> "brickd already running with PIDxxx"

 

Edit: Gerade installiert: Der brickd 1.0.10 verhaelt sich genauso.

 

brickd 1.0.11 behandelt diesen Fall jetzt richtig und auch das Debian Package stoppt jetzt den alten brickd bevor es einen neuen installiert.

[Loetkolben]

Hallo photron,

 

danke fuer die brickd Anpassungen! Scheint auch alles zu funktionieren.

 

# /etc/init.d/brickd start
Starting Brick Daemon: Already running according to /var/run/brickd.pid

 

Der Loetkolben

[macdiverone]

Mit dem Barometer und WLAN kannst du das auch beliebig provozieren.

 

Erst wird die Updatefrequenz im brickv gaaaaanz langsam und dann ist

 

_________________________________________________________ aus… :-/

 

Also Master Brick (Firmware 1.4.6) mit WIFI Extension, Barometer Bricklet (Plugin 1.1.2) versorgt über Step-Down Power Supply. Mit brickv darauf verbunden und seit 1,5 Stunden den Barometer Tab offen und es funktioniert einwandfrei.

 

Tust du da noch was anderes? Verwendest du andere Firmwareversionen?

 

Nein, mal nach 5 Minuten, mal nach 30 Stunden, wobei die kürzeren Zeiten überwiegen… Barometer weg und z.B. Thermometer / IR-Thermometer / Luftfeuchte / Relais dran: runs virtually forever…