(gelöst) OE2.0 rave record buffer overflow detected + inetd down

  • Hallo,


    Ich habe gestern neu wieder OE2.0 experimental auf meine Dm8000 installiert und alle die letzten Updates gespielt. Habe auch eine 1GB swap Partition eingeschaltet.
    Habe nacher viele Aufnahmen programmiert und es hat alles gut geklappt außer ein 13s Aussetzer in einen Aufnahme (Bild angehängt)


    Die Aufnahme hat um 23:20 gestartet und die Aussetzer kommt nach 1:31 Uhr -> Es macht 0:51 Uhr


    Um 0:51, das log sagt:

    Code
    Feb 23 00:51:08 dm8000 user.warn kernel: [16482.366000] rave record buffer overflow detectedrave record buffer overflow detectedrave record buffer overflow detectedrave record buffer overflow detectedrave record buffer overflow detectedrave record buffer overflow dete


    Weisst jemand was bedeutet "rave record buffer overflow detected"
    Ich habe auch das messages log Datei angehängt


    Hat es vielleicht mit dem swap zu tun ? Dieser swap ist wirklich gross in der nacht geworden:

    Code
    top - 00:17:57 up  4:01,  1 user,  load average: 0.33, 0.47, 0.49
    Tasks:  93 total,   1 running,  92 sleeping,   0 stopped,   0 zombie
    Cpu(s):  4.9%us,  8.6%sy,  0.2%ni, 84.9%id,  0.8%wa,  0.0%hi,  0.5%si,  0.0%st
    Mem:	149592k total,   146632k used, 	2960k free, 	6284k buffers
    Swap:  1003280k total,   113772k used,   889508k free,	10408k cached


    Ist es normal mehr als 100MB im swap zu haben ?


    Ein weiteres Problem ist noch dazu gekommen, inetd ist gestorben:


    Es war heute nicht mehr möglich mit ftp einzuloggen

  • Muss ich Euch jetzt auch noch ins Autoswap eine Highwarter Warnung reinmachen die Euch empfielt die Box zu rebooten wenn das swapfile > 50MB benutzt wird?


    Dreht mal die Swappiness auf 0 oder 20 runter, dann sehen wir weiter.

  • die swappiness kannst du auch von hand umdrehen :smiling_face:


    Das Problem ist halt das wenn du 100MB im Swap bist dich nicht wundern darfst wenn auch mal ein wichtiger Prozess dort landet weil er länger nichts zu tun hatte.

  • Hm mag sein, ist mir persönlich aber noch nie passiert. Und ich hab das mit dem Swap schon wochenlang bei mir im Einsatz. Teilweise auch mit mehr als 50MB im Swap ausgelagert. Aber eigentlich swappte es bei mir nur wenn ich es dazu gezwungen hab.

  • Eben und das ist der falsche Weg um sowas zu testen, sondern es muss im normalen Betrieb passieren.


    Ich habe nicht umsonst im BA und SqueezeOut das swappen jetzt permanent aufgedreht, wenn die User es damit ständig mitlaufen haben wissen wir sehr schnell ob es stabil funktioniert und welche negativen Effekte auftreten. Wenn du mit 100MB swappen kannst funktioniert es leider zu gut, und das funktioniert halt nicht auf Dauer ohne negative Effekte


    Linux kann je nach Last mit 20-40% des Memorys im Swapfile noch stabil laufen (womit die 50MB auch nur eine sinnvolle Größenordnung sind) und wenn du mehr hast geht es der Box nicht mehr so tolle - früher oder später.

  • Kleiner Nachtrag - schaut mal mit tip nach wer überhaupt den swap benutzt. Wenn dir das vmstat nicht behagt, mit top geht das relatif leicht wenn man die swap infos mitanzeigen lässt:


    Einfach top in telnet starten, dann f um eine spalte hinzuzufügen und p für die swap infos.

  • Danke für den Tipp...


    Also seit 24h ist den Swap stabil ~35MB beblieben



    Ich habe jetzt ein 720p mkv Movie from CIFS share gestartet (wie Freitag abend) und das Swap kommt plötzlich immer grösser (enigma2)


    Code
    top - 12:26:21 up 1 day,  3:48,  2 users,  load average: 2.74, 2.84, 2.88
    Tasks: 101 total,   2 running,  99 sleeping,   0 stopped,   0 zombie
    Cpu(s): 15.5%us, 21.9%sy,  0.4%ni, 19.2%id, 30.2%wa,  0.2%hi, 12.6%si,  0.0%st
    Mem:	149592k total,   147396k used, 	2196k free, 	1500k buffers
    Swap:  1003280k total,	99312k used,   903968k free,	13696k cached
    
    
      PID USER  	PR  NI  VIRT  RES S %CPU %MEM	TIME+  SWAP COMMAND
      703 root  	20   0  404m  91m S   39 62.8 324:02.94 312m enigma2


    Problem scheint seitens enigma2 zu sein...

    DM7080HD OE2.5 - DM7020HD OE2.0

  • na ja das problem ist das enigma2 sich im Memory einigelt, aber wenn du damit schon > 200MB brauchst das nicht gutgehen KANN und Linux dann sobald das enigma2 ordenlich was zu tun hat irgendwann verzweifelt auch systemrelevante Prozesse ausswapped. Insofern ist da längst ein reboot/enigma2 restart überfällig.


    Aber das ist wie üblich nur die laienhafte Erklärung von einem der davon keine Ahnung hat :grinning_squinting_face:

  • :grinning_squinting_face: Danke für diese Erklärung


    Und es geht weiter.....

    Code
    top - 12:54:31 up 1 day,  4:16,  2 users,  load average: 1.03, 1.31, 1.54
    Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
    Cpu(s): 17.0%us,  8.6%sy,  0.2%ni, 66.2%id,  6.0%wa,  0.0%hi,  2.1%si,  0.0%st
    Mem:	149592k total,   146724k used, 	2868k free,  	584k buffers
    Swap:  1003280k total,   132412k used,   870868k free, 	5024k cached
    
    
      PID USER  	PR  NI  VIRT  RES S %CPU %MEM	TIME+  SWAP COMMAND
      703 root  	20   0  444m 101m S   40 69.4 335:32.46 343m enigma2

    DM7080HD OE2.5 - DM7020HD OE2.0

  • Hmm, normal sind solche hohen werte aber eher nicht.
    Hab in den letzten 2 tagen auch einiges mit der box gemacht (hbbtv,mkv gucken,ftp usw.).


    Code
    top - 13:06:17 up 2 days,  1:54,  1 user,  load average: 0.00, 0.03, 0.05
    Tasks:  84 total,   1 running,  83 sleeping,   0 stopped,   0 zombie
    Cpu(s):  1.2%us,  0.5%sy,  0.0%ni, 98.2%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
    Mem:    149592k total,   142904k used,     6688k free,      332k buffers
    Swap:    72256k total,     4428k used,    67828k free,    26880k cached
    
    
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP COMMAND
    25782 root      20   0  255m 111m  22m S    2 76.0   9:46.13 144m enigma2
  • Und es geht noch weiter, solang das Movie abspielt....


    Code
    top - 13:38:38 up 1 day,  5:00,  2 users,  load average: 0.37, 0.38, 0.58
    Tasks: 100 total,   1 running,  99 sleeping,   0 stopped,   0 zombie
    Cpu(s):  4.7%us,  4.6%sy,  0.0%ni, 89.5%id,  0.7%wa,  0.0%hi,  0.5%si,  0.0%st
    Mem:	149592k total,   136516k used,	13076k free, 	2064k buffers
    Swap:  1003280k total,   176820k used,   826460k free, 	7624k cached
    
    
      PID USER  	PR  NI  VIRT  RES  SHR S %CPU %MEM	TIME+  SWAP COMMAND
      703 root  	20   0  479m  77m 3192 S   11 53.0 344:18.02 402m enigma2

    DM7080HD OE2.5 - DM7020HD OE2.0

  • Nein, ich habe das gleiche Verhältnis vom HDD
    Es passiert fast nichts in die ersten 30 Minuten, es kommt nur nachher...


    Test vom CIFS:


    Test vom HDD (intern SATA HDD):

    DM7080HD OE2.5 - DM7020HD OE2.0

  • Und inet.d ist neu wieder während meine Tests kaputt worden :face_with_open_mouth:


    DM7080HD OE2.5 - DM7020HD OE2.0

  • Hallo,


    xinetd hat neu wieder gecrashed heute (PS: habe am Nachmittag die heutigen Updates installiert und neu gebootet)


    Kernel log:


    Enigma2 log:


    Process xinetd war immer noch im 'ps' liste
    Musste es killen mit '-9' (ohne -9 -> keine Reaction) und neu starten mit "/etc/init.d/xinetd start"

    DM7080HD OE2.5 - DM7020HD OE2.0

  • Hallo,


    Ich habe am Sonntag die neue Experimental Image "dreambox-image-dm8000-20130302.nfi" geflashed und nacher von Null alles neu Konfiguriert.


    Das "xinetd" Problem besteht immer noch und das Automounter hat auch ein Segmentation fault Signal bekommen:


    E2 log:


    und

    DM7080HD OE2.5 - DM7020HD OE2.0

  • Hallo,


    Ich habe heute abend neu wieder alle meine Aufnahmen verloren nach einen "rave record buffer overflow detected".


    Ich habe diesmal das Messages Log und das E2 Log zu verfügung