RED Brick 1.14: Netzwerk sehr instabil (Reboot notwendig).

[linuxmail]

hi,

ich habe das Image aufgespielt. Gibt es eigentlich eine Möglichkeit, die Einstellungen (Hostname/IP/REDBrick LED Einstellungen etc) vorab zu sichern ?

Die Zeit läuft :-)

 

 

bearbeitet December 5, 2019 at 08:55 von linuxmail
Bild getauscht

[linuxmail]

hi,

der Sensor hat dieses mal rund 7 Stunden durchgehalten.

 

[rtrbt]

Was sagt das Kernel-Log? Und steht im Log von deinem Switch was hilfreiches?

Edit: Was mir noch einfiel: Hast du die Probleme jetzt nur noch mit einem der RED-Bricks oder mit beiden?

bearbeitet December 6, 2019 at 09:45 von rtrbt

[linuxmail]

hi,

also, hat etwas gedauert wegen Wochenende etc.

Dec  9 15:36:22 fc-r02-sensor kernel: Packet Size Error 1514>> 28272

Der Switch selbst zeigt nichts auffälliges. Der zweite REDBrick hält bisher durch. Der ist nach wie vor im original Zustand, ohne jegliches Update, nur der angepasste Kernel.
Es gibt allerdings sehr wenige Meldungen diesbezüglich, nicht so wie vor dem neuen Kernel.

Edit: Oh, dieses mal waren es nur wenige Minuten, eventuell, weil ich den Netzwerkstecker gezogen habe, um den Port auf dem Switch zu verifizieren.

Soll ich den RedBrick oder alles mal zu euch senden ?

bearbeitet December 10, 2019 at 09:58 von linuxmail
Edit hinzugefügt

[rtrbt]

Moin,

Das sieht nach einem neuen Problem oder zumindest einer neuen Ausprägung aus. Ich habe dir mal wieder einen Kernel mit Debug-Ausgaben angehangen, wenn du das mit dem reproduzieren kannst, schick nochmal das ganze Kernel-Log. (Der interessante Teil beginnt dann mit dem Packet Size Error und endet mit "Dump done.")

Hier her senden würde vermutlich nicht viel helfen, den Fehler habe ich so auch noch nicht gesehen, da vermute ich mal, dass die Umgebung mit reinspielt.

linux-image-4_13.0-red-brick-1_4_13.0-red-brick-1_armhf.deb

[linuxmail]

hi,

eventuell übersehe ich was. Die komplette Log hängt dran. Er hat keine 30 Minuten gehalten.

Der Switch sagt:

W 12/10/19 15:23:06 02672 FFI: ST1-CMDR: port 3/14-Excessive link state transitions

Allerdings sehe ich sowas auch bei anderen Rechnern. Das ist meistens das Energie Management.

kern_mess_sys.tar.gz

[rtrbt]

Hm, du hast da noch einen alten Kernel laufen, das sehe ich an dieser Meldung:

fc-r02-sensor kernel: ring_buf_dump: f->f_op->write_iter

(das ist der Debug-Code für das andere Problem, der ist nicht mehr drin)

Du kannst dir mit uname -v die Zeit ausgeben lassen, zu der der Kernel kompiliert wurde. Das ist beim richtigen

#10 Tue Dec 10 12:27:26 CET 2019

Hast du vielleicht die Pakete vertauscht?

[linuxmail]

Du hast Recht, da der Name der Datei gleich war, habe ich das alte Paket hochgeladen. Das Interessante bisher: kein Aussetzer mehr.

tf@fc-r02-sensor:~$ uname -v
#10 Tue Dec 10 12:27:26 CET 2019
tf@fc-r02-sensor:~$ uptime
 11:55:55 up 1 day, 46 min,  3 users,  load average: 1.32, 1.15, 1.02

Ich hatte allerdings so ein kleines ziehen im Bauch und habe auch mal das USB Kabel gegen ein anderes getauscht. Wenn der Brick die Woche übersteht, wechsel ich noch einmal auf das "alte" Kabel.

[linuxmail]

hi,

das Wochenende ist rum und das Netzwerk funktioniert noch immer :-) Wäre es denkbar, dass auch das USB Kabel eine sehr erhebliche Rolle spielt ?

[rtrbt]

Wäre möglich, dann ist das vermutlich ein Stromversorgungsproblem. Das würde dann auch erklären warum der eine RED-Brick das hat und der andere nicht. Kannst ja nochmal zurücktauschen

[linuxmail]

hi,

also, ich habe zurück getauscht und bisher immer noch kein Problem. Ich vermute, dass nur ein schräges anschauen des USB- oder Netzwerkkabels das auslösen :-)

[rtrbt]

Das klingt doch erstmal gut :)

[linuxmail]

Einen schönen guten Morgen und ein glückliches neues Jahr :-)

Der RedBrick hat sich am 24.12.2019 (!!) um ~05:11 komplett verabschiedet :-D und das nach mehreren Tagen durchhalten (3-4 Tage).

Anbei mal wieder ein Archiv mit Logs. Eventuell entdeckst du da etwas neues.

Viele Grüße

Denny 

dump_logs.tar.gz

[rtrbt]

Uff, ein Weihnachtswunder :D

Ich bin diese Woche noch im Urlaub, nächste Woche melde ich mich dann nochmal.

[linuxmail]

hi,

macht nix, ich hatte da eh nicht die Tage mit einer Antwort gerechnet 😉 Ich habe das Konstrukt jetzt einfach dochmal ins RZ gebracht, um endlich mal das Ticket schließen zu können. Ich hoffe jetzt einfach mal, dass der durchläuft ...

cu denny

[linuxmail]

hi,

neuer Tag .... altes Problem 🙂 Auch im RZ (näher zu Fuß, aber mit sehr viel mehr Fluchen verbunden, wegen Enge) hat sich der RED Brick verabschiedet. Meine Hoffnung, dass ich durch einen Reboot des Rechners -- von dem der Stapel seinen Strom bekommt --  den REDBrick stromlos bekomme, hat sich leider zerschlagen, sodass ich hinlaufen muss ... zum Stecker ziehen.

Das Netzwerk ist dort kein HP, sondern ein Ubiquitiy EdgeSwitch. Gleiches Konstrukt wie in unserem anderen RZ ... Eventuell sollte man dochmal darüber nachdenken, den RedBrick zu tauschen, samt SD Karte ...
Solang der nicht stabil läuft, kann ich die Icinga2 Benachrichtigungen nicht aktivieren 🙂

cu denny

bearbeitet January 9, 2020 at 10:59 von linuxmail
Syntax

[linuxmail]

hi,

per Cron lasse ich jeden Morgen um 7Uhr einen Reboot durchführen. Außerdem hängt er per Adapter nun an einer PDU, sodass ich mir den Weg dahin sparen kann. Interessant war noch, als ich auf dem Jumper Brickv habe laufen lassen, dass nur der REDBrick gelistet wurde, aber sonst nichts. Das kenne ich auch anders. Brickv gab mir sogar die Möglichkeit einen Reboot durchzuführen, aber hat nicht geklappt, außer dass Brickv leer war danach.
Eventuell hilft dir das mehr.

Wenn wir tauschen sollten ... wende ich mich an TinkerForge, oder soll ich das über Netways abwickeln lassen ? (die wissen aktuell noch nichts von den Problemen)

cu denny

[linuxmail]

hi,

nur so als info: Reboot jeden Tag hat nicht geholfen ... konnte aber prüfen, ob ich die Dose der PDU korrekt beschriftet habe und nicht den falschen resetet habe 🙂

[rtrbt]

Moin,

Bezüglich der Brick Viewer-Probleme: Das die am RED-Brick angeschlossene Hardware nicht auftaucht klingt nach einem Enumerierungsproblem. Du hast echt verfluchte Hardware. Wenn du den Reboot per Brick Viewer machst, merkt der Brick Viewer dass die Verbindung weg ist? (Dann steht im Button oben nicht mehr disconnect sondern abort pending automatic reconnect) Falls ja, sollte die Verbindung eigentlich nachdem der RED-Brick wieder gebootet und verbunden ist (nach ungefähr einer Minute bei mir) wieder aufgebaut werden.

Tauschen klingt nach einer guten Idee, dann kann ich das eventuell hier weiter untersuchen. Schreib mal eine E-Mail mit Adressdaten usw. an nicolai@tinkerforge.com (er ist heute schon weg, sonst hätte ich das gerade angeschubst). Wenn du reinschreibst, dass er mich (Erik) mal fragen soll musst du nicht die ganze Vorgeschichte anhängen.

[linuxmail]

Hi,

der Reboot via Brickviewer hat nur bewirkt, dass der Viewer dann leer war. Auch ein Disconnect / Connect bracht keine Abhilfe. Ich nehme dann einfach an, dass der RED sich vom USB abgemeldet hat und weg blieb. Wer weiß 🙂 Nach Strom Raus/Rein läuft dann alles wieder für ein paar Tage.

Ich melde mich mal bei Nicolai und wickel dann darüber alles nötige ab.

Ich bin schon sehr gespannt, ob es an meiner Unfähigkeit liegt / lag, oder ob es tatsächlich eine "kalte Lötstelle ist" 😄

cu denny

[rtrbt]

Moin,

Ich habe den RED-Brick hier mal getestet, aber alles hat funktioniert. Hast du den Austausch-Brick schon getestet? Viell stört da ja doch einfach irgendwas in der Umgebung drauf.

[linuxmail]

hi,

ich hatte vermutet ihr sprecht miteinander 🙂 Sorry. Also, es gab überhaupt kein Problem mehr. Weder hat das Netzwerk ausgesetzt, noch hat sich der REDBrick aufgehangen. Auch der andere hat keinerlei Probleme. Allerdings wurde beim zweiten auch das Netzwerkmodul getauscht, nach Absprache mit dir.
Beide im RZ haben eins gemeinsam: sie haben keinerlei Updates gesehen. Das habe ich mich nicht mehr getraut 😉

cu denny

[rtrbt]

Das klingt doch gut, danke für die Rückmeldung!