linuxmail Posted November 25, 2019 at 02:08 PM Share Posted November 25, 2019 at 02:08 PM (edited) Hallo, ich habe das Rack Monitoring Set von Netways gekauft und dabei ist ein RED Brick, der sehr oft die Netzwerkverbindung komplett verliert, sodass ein Reboot / Reset notwendig ist. Im Terminal sehe ich im (Milli-)Sekundentakt: kernel: socket_send(84000): free_buf_size 2048 Ich dachte erst, dass es eventuell mit der Spannung zu tun haben könnte (zu wenig), aber in der Log finde ich noch: NetworkManager assertion '<dropped>' failed ... : <info> [1574689760.6530] device (tf0): driver 'w5x00' does not support carrier detection. Das habe ich mehrfach pro Tag, bzw. sogar in der Stunde. Ich habe auch von DHCP auf statisch umgestellt, brachte aber keine Änderung. Über Google habe ich folgendes gefunden: https://access.redhat.com/solutions/894763 Das ist zwar ein leicht anderes Problem, aber eventuell kann es helfen, ebenfalls "ignore-carrier=no" zu setzen. Hat jemand schon änliches beobachtet ? cu denny Edited November 25, 2019 at 02:08 PM by linuxmail Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 25, 2019 at 02:34 PM Author Share Posted November 25, 2019 at 02:34 PM hi, möglicherweise ist die Ursache, dass ich zu häufig mein check_tinkerforge_py aufrufe (alle 2 sec): borg replied to a topic sicher bin ich mir aber nicht, ob dies die Ursache ist. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 25, 2019 at 02:51 PM Share Posted November 25, 2019 at 02:51 PM Moin, Dein Problem scheint zu sein, dass der Ethernet-Chip seine Daten nicht senden kann. Das sollte nichts mit Spannungsproblemem, DHCP oder der Anzahl der Verbindungen zu tun haben. Zum Debuggen bräuchte ich Informationen aus dem Kernel-Log, konkret die Ausgabe folgender Befehle auf dem Terminal: dmesg | grep -C 5 "PHY RESET" dmesg | grep ": socket(" dmesg | grep "socket_send(100000)" Gruß, Erik Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 26, 2019 at 10:03 AM Author Share Posted November 26, 2019 at 10:03 AM hi, noch vorab: der Switch (HP 2920) sagt mir folgendes: I 11/25/19 15:41:05 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 15:41:03 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 15:40:46 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 15:40:44 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:59:46 00076 ports: ST1-CMDR: port 2/17 is now on-line W 11/25/19 14:59:46 02672 FFI: ST1-CMDR: port 2/17-Excessive link state transitions I 11/25/19 14:59:44 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:59:39 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:59:38 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:46:12 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:46:09 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:45:06 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:45:04 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:16:40 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:16:38 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:16:34 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:16:32 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:16:13 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:16:08 00077 ports: ST1-CMDR: port 2/17 is now off-line I 11/25/19 14:15:09 00076 ports: ST1-CMDR: port 2/17 is now on-line I 11/25/19 14:15:07 00077 ports: ST1-CMDR: port 2/17 is now off-line Bevor ich los musste, trat der Fehler wieder auf, root@sensor:~# dmesg | grep "socket_send(100000)" [ 3584.279511] socket_send(100000): free_buf_size 2048 [ 3606.208238] socket_send(100000): free_buf_size 2048 [ 3628.239347] socket_send(100000): free_buf_size 2048 [ 3650.040685] socket_send(100000): free_buf_size 2048 [ 3671.958557] socket_send(100000): free_buf_size 2048 [ 3693.702808] socket_send(100000): free_buf_size 2048 [ 3715.459370] socket_send(100000): free_buf_size 2048 [ 3737.385853] socket_send(100000): free_buf_size 2048 [ 3759.113768] socket_send(100000): free_buf_size 2048 [ 3802.223223] ----PHY RESET---- [ 3802.628726] socket_send(1000): free_buf_size 2048 [ 3803.040922] socket_send(2000): free_buf_size 2048 [ 3803.450726] socket_send(3000): free_buf_size 2048 [ 3803.852613] socket_send(4000): free_buf_size 2048 [ 3804.262684] socket_send(5000): free_buf_size 2048 -- [ 3843.850824] socket_send(96000): free_buf_size 2048 [ 3844.261495] socket_send(97000): free_buf_size 2048 [ 3844.675212] socket_send(98000): free_buf_size 2048 [ 3845.076846] socket_send(99000): free_buf_size 2048 [ 3845.487318] socket_send(100000): free_buf_size 2048 [ 3845.487730] ----PHY RESET---- [ 3845.901585] socket_send(1000): free_buf_size 2048 [ 3846.304035] socket_send(2000): free_buf_size 2048 [ 3846.714713] socket_send(3000): free_buf_size 2048 [ 3847.116583] socket_send(4000): free_buf_size 2048 root@sensor:~# dmesg | grep "socket_send(100000)" [ 3584.279511] socket_send(100000): free_buf_size 2048 [ 3606.208238] socket_send(100000): free_buf_size 2048 [ 3628.239347] socket_send(100000): free_buf_size 2048 [ 3650.040685] socket_send(100000): free_buf_size 2048 [ 3671.958557] socket_send(100000): free_buf_size 2048 [ 3693.702808] socket_send(100000): free_buf_size 2048 [ 3715.459370] socket_send(100000): free_buf_size 2048 [ 3737.385853] socket_send(100000): free_buf_size 2048 [ 3759.113768] socket_send(100000): free_buf_size 2048 [ 3802.222666] socket_send(100000): free_buf_size 2048 Ich denke, es wird nicht lange dauern, bis das Problem wieder auftritt, dann reiche ich noch nach, was ich vergaß. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 26, 2019 at 11:10 AM Share Posted November 26, 2019 at 11:10 AM Moin, Die Ausgaben sehen so aus, wie erwartet. Die Logs aus deinem Switch dürften zeitlich mit den PHY-Resets zusammenfallen. Das Problem scheint zu sein, dass die Ethernet-Extension 14kb an Netzwerkdaten verschicken will, aber die aus irgendeinem Grund nicht hinbekommt. Nachdem das eine Weile nicht funktioniert hat, löst der Treiber den Reset aus um irgendwie wieder auf einen sinnvollen Zustand kommt. Ich versuche das hier mal nachzustellen und melde mich dann nochmal. Gruß, Erik Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 26, 2019 at 11:12 AM Author Share Posted November 26, 2019 at 11:12 AM hi, wenn du magst, kann ich dir nochmal frische DMESG Ausgaben als txt anhängen. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 26, 2019 at 12:15 PM Share Posted November 26, 2019 at 12:15 PM Mach mal, das schadet bestimmt nicht. Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 26, 2019 at 01:07 PM Author Share Posted November 26, 2019 at 01:07 PM Hi, hängt dran. socket.txt socket_sent.txt phy_reset.txt Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 26, 2019 at 03:37 PM Share Posted November 26, 2019 at 03:37 PM Danke, eine Frage noch: was machst du mit dem RED-Brick, wenn du das reproduzierst? Lässt du irgendwelche Software laufen oder einfach Idle + SSH oder sowas? Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 26, 2019 at 07:51 PM Author Share Posted November 26, 2019 at 07:51 PM Hi, tatsächlich einfach nur ein ping am Ende oder parallel noch das check_tinkerforge.py Icinga Plugin, damit ich mitbekomme, wenn das Netzwerk wieder tot ist. Cu denny Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 27, 2019 at 07:19 AM Author Share Posted November 27, 2019 at 07:19 AM Guten Morgen, ich weiß nicht, ob das von Bedeutung ist ... manchmal passiert es, dass beim (USB) Strom ziehen und wieder reinstecken der RedBrick nicht "an" geht. Die blaue status LED bleibt aus. Erst beim wiederholten aus/einstecken geht der RedBrick wieder an. Die übrigen Bricks dagegen leuchten (blau). Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 27, 2019 at 12:42 PM Share Posted November 27, 2019 at 12:42 PM Moin, Ich habe das ganze hier reproduzieren können. Ich melde mich, wenn ich mehr weiß. 5 hours ago, linuxmail said: manchmal passiert es, dass beim (USB) Strom ziehen und wieder reinstecken der RedBrick nicht "an" geht. Die blaue status LED bleibt aus. Erst beim wiederholten aus/einstecken geht der RedBrick wieder an. Die übrigen Bricks dagegen leuchten (blau). Kannst du, wenn das Anstecken nichts tut, den RED-Brick mit dem Power-Knopf starten (Braucht so 2-3 Sekunden, der Knopf ist links neben der USB-Buchse) oder musst du dann das Kabel neu aus-/einstecken? 1 Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 27, 2019 at 01:00 PM Author Share Posted November 27, 2019 at 01:00 PM hi, da warst du nun schneller als ich. Ich habe den zweiten RZ Sensor aufgebaut, in der Hoffnung, es wäre ein Firmware / Update Problem, oder auch Hardware ... ... spoiler: ist es nicht :-) Ich bin gespannt ... Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 29, 2019 at 09:59 AM Author Share Posted November 29, 2019 at 09:59 AM hi, habt ihr schon eine Idee, wie ihr das Problem lösen könnt ? Ich vermute, ihr erstellt einen Git(hub|lab) Ticket irgendwo :-) Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 29, 2019 at 10:56 AM Share Posted November 29, 2019 at 10:56 AM Moin, Ich bin dem ganzen in den letzten Tagen mal nachgegangen. Du kannst mal den angehangenen Kernel testen, der im Modul für die Ethernet-Extension zwei Änderungen hat: Falls das Problem nochmal auftritt (und direkt zum Start einmal), werden im Wurzelverzeichnis ring_buf_dump-Dateien angelegt, die jeweils die letzten 4 Pakete, die gesendet wurden enthalten. (Das hilft mir beim Debuggen). Zweitens habe ich einen möglichen Fix für das Problem (siehe unten) gefunden, deshalb kannst du das mal testen. Ich lasse hier auch zwei RED-Bricks über das Wochenende laufen, bisher haben sie 18 Stunden ausgehalten. Um den Kernel zu installieren musst du das angehangene Paket auf den RED-Brick schieben (z.b. mit scp), dann den alten Kernel mit sudo apt purge linux-image-4.13.0-red-brick-1 deinstallieren und den neuen Kernel mit sudo dpkg -i linux-image-4.13.0-red-brick-1_4.13.0-red-brick-1_armhf.deb installieren und den RED-Brick neustarten. Ob es geklappt hat siehst du daran, dass dann nach dem Neustart im Wurzelverzeichnis eine Datei namens ring_buf_dumpI existieren sollte. Die hässlichen Details: Der Ethernet-Chip hat einen Sende-/Empfangsbuffer von jeweils 16384 Byte, die man auf bis zu 8 Sockets verteilen kann. Standardeinstellung sind 2048 Byte pro Socket. Der Treiber konfiguriert das auf 16384 Byte für den ersten Socket und 0 für alle anderen um, da nicht die Sockets des Chips verwendet werden, sondern der Kernel n Sockets in Software auf den ersten Socket in Hardware multiplext. Der Chip scheint aber nach einer Weile die Konfiguration zu vergessen, und setzt sie wieder auf 8 * 2048 Byte. Der Treiber wartet dann endlos, bis die 16384 Byte des ersten Sockets wieder freiwerden, bevor er ein Paket als verschickt interpretiert, was dann aber nie passieren kann (das erzeugt dann die Ausgabeflut im Kernel-Log). Ich hatte erst getestet, in dem Fall die Konfiguration wieder umzustellen, aber dann hing der Chip komplett. Stattdessen lasse ich es jetzt gleich zu Anfang auf 8 * 2048 Byte, die maximale MTU ist sowieso auf ~1500 Byte hardgecodet, nur beim Empfangen hätte sich eventuell mehr gelohnt, das muss ich nochmal in Ruhe testen. linux-image-4_13.0-red-brick-1_4_13.0-red-brick-1_armhf.deb Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 29, 2019 at 12:18 PM Author Share Posted November 29, 2019 at 12:18 PM hi, das nenne ich einen guten Support :-) Ich habe den Kernel eingespielt und lasse die beiden nun auch ein paar Tage laufen. Mal schauen, was so passiert. Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 29, 2019 at 02:43 PM Author Share Posted November 29, 2019 at 02:43 PM hi, rund 2-3 Stunden :-) ring_buf_dumpI hängt dran. ring_buf_dumpI Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 29, 2019 at 02:50 PM Share Posted November 29, 2019 at 02:50 PM Du meinst, 2-3 Stunden bis die Netzwerkverbindung wieder weg war? Was sagt das Kernel-Log dazu? (dmesg oder /var/log/messages) Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 29, 2019 at 03:06 PM Author Share Posted November 29, 2019 at 03:06 PM hi, der war wohl doch schon schneller weg. Ich habe dir den Zeitraum (13:xx) mal angehangen. Um 15:39 habe ich den Stecker gezogen, ist aber nicht mehr in der Log. kern.log Quote Link to comment Share on other sites More sharing options...
rtrbt Posted November 29, 2019 at 03:12 PM Share Posted November 29, 2019 at 03:12 PM Hm, das ist seltsam, im Log sehe ich nur, wie 13:15 der neue Kernel startet, danach kommt nichts mehr. War das eventuell ein anderes Problem? Was macht der zweite RED-Brick? Quote Link to comment Share on other sites More sharing options...
linuxmail Posted November 29, 2019 at 03:36 PM Author Share Posted November 29, 2019 at 03:36 PM (edited) hi, sehr seltsam. In der tat. Ich habe jetzt mal ein Tar erzeugt. Da ist die komplette kern.log messages und nochmal die /ring_buf_dumpI drin. Es war auch der richtige Host, da der hinter mir steht. Ich musste allerdings ein wenig umbauen, da mein Rechner ein Laptop ist und der mitgenommen wird ... da wäre das mit dem Strom schwierig :-) Daher kann ich da nicht mehr direkt auf die serielle Konsole. Da sich das hier zu einem Chat entwickelt ... sollen wir hier verbleiben, oder zu einem Github / Redmine / Gitlab / ... oder was auch immer ihr verwendet übergehen ? Mail geht natürlich auch (alternativ Matrix.org, wenn ihr das rein zufällig verwendet). Dem zweiten geht es bisher immer noch gut. Das ist der ohne Updates. debug.tar.gz Edited November 29, 2019 at 03:37 PM by linuxmail Quote Link to comment Share on other sites More sharing options...
linuxmail Posted December 2, 2019 at 08:02 AM Author Share Posted December 2, 2019 at 08:02 AM Guten Morgen, was ich nicht so verstehe ist, dass der RED ohne jegliches Update erheblich seltener ohne Netzwerk darsteht, als der mit allen Updates. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted December 2, 2019 at 09:43 AM Share Posted December 2, 2019 at 09:43 AM Moin, On 11/29/2019 at 4:36 PM, linuxmail said: hi, sehr seltsam. In der tat. Ich habe jetzt mal ein Tar erzeugt. Da ist die komplette kern.log messages und nochmal die /ring_buf_dumpI drin. Es war auch der richtige Host, da der hinter mir steht. Ich musste allerdings ein wenig umbauen, da mein Rechner ein Laptop ist und der mitgenommen wird ... da wäre das mit dem Strom schwierig 🙂 Daher kann ich da nicht mehr direkt auf die serielle Konsole. Hm im Log sind keine hilfreichen Aussagen drin, die ring_buf_dumpI ist übrigens nur die, die zum Systemstart angelegt wird, damit teste ich nur ob das Dateien schreiben aus dem Kernelmodul klappt. On 11/29/2019 at 4:36 PM, linuxmail said: Da sich das hier zu einem Chat entwickelt ... sollen wir hier verbleiben, oder zu einem Github / Redmine / Gitlab / ... oder was auch immer ihr verwendet übergehen ? Mail geht natürlich auch (alternativ Matrix.org, wenn ihr das rein zufällig verwendet). Ich würde das erstmal hier lassen, ist ja eventuell für die Nachwelt relevant. 1 hour ago, linuxmail said: was ich nicht so verstehe ist, dass der RED ohne jegliches Update erheblich seltener ohne Netzwerk darsteht, als der mit allen Updates. Mit den Updates meinst du über apt oder den Kernel den ich dir gegeben habe? Die beiden RED-Bricks hier haben das Wochenende mit dem modifizierten Kernel übrigens gut überstanden, d.h. eventuell hast du noch ein zusätzliches Problem. Quote Link to comment Share on other sites More sharing options...
linuxmail Posted December 2, 2019 at 10:07 AM Author Share Posted December 2, 2019 at 10:07 AM hi, mit den Updates meine ich die, die per "brickv" durchgeführt werden. Der, der gar keine Updates gesehen hat (also aus dem Karton raus und so belassen) hat auch das Wochenende überstanden, während der, der alle Updates erhalten hat, sich mittlerweise im kurzen Takt verabschiedet. Aktuell war der schon nach runder einer Stunde weg. In den Logs gibt es tatsächlich garnichts. Wäre man eingeloggt, würde man es nur daran merken, dass ntpd sich beklagt, weil DNS nicht mehr funktioniert. Quote Link to comment Share on other sites More sharing options...
rtrbt Posted December 3, 2019 at 03:58 PM Share Posted December 3, 2019 at 03:58 PM Moin, Teste mal mit dem (neuen) RED Brick Image 1.15. Ich quäle den Aufbau hier seit einiger Zeit mit iperf und bisher funktioniert es. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.