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

[linuxmail]

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

bearbeitet November 25, 2019 at 14:08 von linuxmail

[linuxmail]

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.

 

[rtrbt]

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

[linuxmail]

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ß.

[rtrbt]

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

[linuxmail]

hi,

wenn du magst, kann ich dir nochmal frische DMESG Ausgaben als txt anhängen.

[rtrbt]

Mach mal, das schadet bestimmt nicht.

[linuxmail]

Hi,

hängt dran.

socket.txt socket_sent.txt phy_reset.txt

[rtrbt]

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?

[linuxmail]

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

[linuxmail]

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).

[rtrbt]

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?

[linuxmail]

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 ...

[linuxmail]

hi,

habt ihr schon eine Idee, wie ihr das Problem lösen könnt ? Ich vermute, ihr erstellt einen Git(hub|lab) Ticket irgendwo :-)

[rtrbt]

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

[linuxmail]

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.

 

[linuxmail]

hi,

rund 2-3 Stunden :-)  ring_buf_dumpI hängt dran.

ring_buf_dumpI

[rtrbt]

Du meinst, 2-3 Stunden bis die Netzwerkverbindung wieder weg war? Was sagt das Kernel-Log dazu? (dmesg oder /var/log/messages)

[linuxmail]

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

[rtrbt]

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?

[linuxmail]

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

bearbeitet November 29, 2019 at 15:37 von linuxmail

[linuxmail]

Guten Morgen,

was ich nicht so verstehe ist, dass der RED ohne jegliches Update erheblich seltener ohne Netzwerk darsteht, als der mit allen Updates.

[rtrbt]

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.

[linuxmail]

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.

[rtrbt]

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.