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

linuxmail · November 25, 2019 at 14:08

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 · November 25, 2019 at 14:34

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 · November 25, 2019 at 14:51

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 · November 26, 2019 at 10:03

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 · November 26, 2019 at 11:10

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 · November 26, 2019 at 11:12

hi,

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

rtrbt · November 26, 2019 at 12:15

Mach mal, das schadet bestimmt nicht.

linuxmail · November 26, 2019 at 13:07

Hi,

hängt dran.

socket.txt socket_sent.txt phy_reset.txt

rtrbt · November 26, 2019 at 15:37

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 · November 26, 2019 at 19:51

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 · November 27, 2019 at 07:19

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 · November 27, 2019 at 12:42

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 · November 27, 2019 at 13:00

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 · November 29, 2019 at 09:59

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 · November 29, 2019 at 10:56

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 · November 29, 2019 at 12:18

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 · November 29, 2019 at 14:43

hi,

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

ring_buf_dumpI

rtrbt · November 29, 2019 at 14:50

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

linuxmail · November 29, 2019 at 15:06

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 · November 29, 2019 at 15:12

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 · November 29, 2019 at 15:36

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 · December 2, 2019 at 08:02

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 · December 2, 2019 at 09:43

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 · December 2, 2019 at 10:07

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 · December 3, 2019 at 15:58

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.

Anmelden

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

Recommended Posts

linuxmail

linuxmail

rtrbt

linuxmail

rtrbt

linuxmail

rtrbt

linuxmail

rtrbt

linuxmail

linuxmail

rtrbt

linuxmail

linuxmail

rtrbt

linuxmail

linuxmail

rtrbt

linuxmail

rtrbt

linuxmail

linuxmail

rtrbt

linuxmail

rtrbt

Join the conversation

Umsehen

Aktivitäten