sectionsd stopt nicht bei der Aufnahme

[seife]

Martin, siehst du denn dasselbe im Log wie bellum?
Das ist nämlich ein echter Bug und der könnte zu sowas führen (sectionsd belegt die Maschine ziemlich komplett, obwohl er pausieren sollte).

[MPC823]

Hi @all

Danke mal vorab.

Die "queue 0 overflow" sehe ich deutlichst im log. Ich habe aber gedacht das ist ein Problem des sectionsd der das verursacht da er nicht schläft oder so.

Ich bin zu allen schandtaten bereit wenn Ihr mir sagen könnt was ich machen soll um den Fehler weiter einzukreisen.


Gruss Martin

P.S Axo den Patch von Seife habe ich mal eingebaut und neu gebaut. Ich muss aber erst mal kontollieren ob der dann auch wirklich drin ist ich bin mir da nicht immer so sicher wenn das ganze durchläuft heisst es ja noch lange nicht das das was ich gemacht habe auch funktioniert bzw dies oder das bei herhauskommt. Werde mal den Printf statment wieder anschalten dann sollte es man ja sehen. Was ich aber gemacht habe den status des sectionsd abgefragt und der war pausierend bei der aufnahme und working danach

[MPC823]

Ich hab den Thread mal gesucht und festgestellt, daß es deiner war:

Ähm das hatte ich wohl schon etwas verdrängt

Also die Interpretation von queue 0 overflow bedeutet was ich hier im Forum fand, daß der Pufferinhalt im Demux-RAM nicht schnell genug von der CPU abgeholt wird .

Da die 500/600 Hardwaremässig identsich sind bis auf die Avias sind diese dann auch Performance gleich. Was mir aufgefallen ist war das die 500er deutllichst agiler in der Bedienung ist im vergleich zur 600er. Dies muss irgendwie mit dem Treiber für den AVIA und dem sectionsd zusammenhängen da wenn ich den sectionsd kille keine Probleme habe.
Die AVIA's haben ja auch geringfüge Unterschiede was die können evt auch wie die angesprochen und initialisiert werden (nicht nur durch den ucode) evt liegt da der Hund begraben das da irgendwas falsch initialisiert wird oder angesprochen und dabei eben es zu einem "timeout" kommt was das zähe verhalten erklären würde.

Mal sehen ob man das irgendwie herausbekommen kann. Ich denke das ist eine richtige Sissifuz Arbeit aber die 500er Boxen Beweisen ja das es gehen muss.


Martin

[seife]

ich meinte nicht den queue overflow, sondern das ständige Triggern vom CNThread.

Aber ja, ich kanns reproduzieren: DeluxeMusic einschalten, warten bis sectionsd durch ist mit einlesen, "sectionsdcontrol --pause", warten bis zum nächsten Lied => bumm. Allerdings belastet es die Kiste nicht übermässig:

Code: Alles auswählen

top - 09:48:00 up 4 days, 14:45,  0 users,  load average: 0.13, 0.23, 0.17
Tasks:  33 total,   1 running,  32 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.2%us, 14.2%sy,  1.2%ni, 78.7%id,  0.0%wa,  0.6%hi,  0.0%si,  0.0%st
Mem:     30324k total,    25056k used,     5268k free,     1156k buffers
Swap:        0k total,        0k used,        0k free,     5632k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  2460 root      -2  10 67484 7596  924 S 30.8 25.0  36:31.83 sectionsd
   233 root      15  -5     0    0    0 S  6.2  0.0 642:17.23 dmx_wq/0
  3488 root      20   0  1764  820  668 R  5.9  2.7   0:04.32 top
   351 root      20   0  3824 1816  800 S  1.2  6.0  79:51.68 zapit
   356 root      20   0 53048 6328 2640 S  1.2 20.9  77:16.63 neutrino
     1 root      20   0  1884  476  408 S  0.0  1.6   0:01.40 init

Aber bei einer Aufnahme kann das u.U. das sein, was sie über die Klippe stürzt. Und die RT prio vom sectionsd main Thread beisst uns hier evtl...
Es ist nicht zufällig so, dass du auf der 500er Box einen 2.4er und auf der 600er einen 2.6er Kernel hast (oder andersrum?)

[MPC823]

Ich habe auf beiden Boxen das gleiche Image mit 2.4er Kernel drauf was ich mit dem letzten Snapshot von mit ich glaube es war der 6.06.08 gemacht hatte.

Was man halt eben auch merkt ist das die 500er Box deutlichst flotter ist was man sehr deutlich merkt sobald man aufnimmt.


Martin

[bellum]

Probiert mal das:

Code: Alles auswählen

Index: dmx.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/daemons/sectionsd/dmx.cpp,v
retrieving revision 1.36
diff -u -p -r1.36 dmx.cpp

bin leider nicht eher zum testen gekommen...

Habe zwar Anfang der Woche Deinen Patch in den sectionsd eingebaut, konnte aber die Aufnahme noch nicht testen.
Kann lediglich sagen, dass mir im normalen Betrieb nichts negatives aufgefallen ist. Werde nun übers Wochenende noch ein paar Aufnahmen manchen und berichten. Ich habe hier im Kabel auch Deluxe Music, aber die Affen senden kein EPG mit Muss dann halt normale Aufnahmen machen...

Ist das dann eigentlich der offizielle Fix oder kommt da noch was anderes?

Was mir noch aufgefallen ist und ich hier auch in einem Posting von MPC823 gesehen habe. Top zeigt mir folgendes an:

Code: Alles auswählen

Mem: 21732K used, 9156K free, 0K shrd, 0K buff, 9092K cached
Load average: 0.05 0.08 0.07
  PID  PPID USER     STAT   VSZ %MEM COMMAND
  152     1 root     S    64116 207% sectionsd
  153   152 root     S    64116 207% sectionsd
  155   153 root     S    64116 207% sectionsd
  156   153 root     S    64116 207% sectionsd
  157   153 root     S    64116 207% sectionsd
  158   153 root     S    64116 207% sectionsd
  159   153 root     S    64116 207% sectionsd
  160   153 root     S    64116 207% sectionsd
  161   153 root     S    64116 207% sectionsd

Wie kann man mehr als 100% RAM verbrauchen? Ist da was mit top schief?

Gruß
bellum

[mohousch]

Wie kann man mehr als 100% RAM verbrauchen? Ist da was mit top schief?

bei busybox-top das ist normal,er berechnet die VSZ im Byte auf das Mem in KByte.

[MPC823]

Wie kann man mehr als 100% RAM verbrauchen? Ist da was mit top schief?

bei busybox-top das ist normal,er berechnet die VSZ im Byte auf das Mem in KByte.

und wie ruft Ihr dann immer top auf oder habt Ihr eine eigenständige top version laufen ?

Wie wäre den folgende Idee um an den Bug zwischen der 500<->600 Nokia ranzukommen.

Eine debug Ausgabe in jede Funktion des sectiond einbauen . Ich denke mal am besten in eine file schreiben nennen wir es mal sectionsd.log nach /tmp .

Dann beide Boxen auf ARD schalten evt ist da schon ein Unterschied im log enthalten und dann mal aufnehmen. Da die Boxen sich ja unterschiedlich verhalten müssten dann ja Unterschiede zu sehen sein oder ?

Falls dies Sinnfrei sein sollte hätte jemand einen besseren Vorschlag ?


Martin

[MPC823]

Ich habe mir nun folgendes überlegt um die Sache erst mal eingrenzen zu können.

Mit top auf beiden Boxen zur gleichen Zeit schauen welche prozess Abweichungen hat sofern man das sieht.

Nun habe ich mir ein binary für den ppc besorgt . Leif natürlich wegen dem ganzen lib gequarke nicht. Dann habe ich mir das Paket von sourceforge geholt und top neu gebaut und alles statisch gelinkt. Das Binary ist zwar nun ein bischen gross aber in /tmp hat es ja genug Platz. Nun bekomme ich folgenen Fehlermeldung

/tmp # ./top
Floating point exception
/tmp #

Kann das mit dem Kernel zusammenhängen ?
Dbox :

/tmp # cat /proc/version
Linux version 2.4.36.2-dbox2 (martin@MacMini) (gcc version 3.4.6) #42 Mo 30. Jun
08:41:27 CEST 2008
/tmp #

Mac :

martin@MacMini:~/sourcecodes/procps-3.2.7$ cat /proc/version
Linux version 2.6.18-5-powerpc (Debian 2.6.18.dfsg.1-13etch1) (dannf@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Sun Aug 12 21:01:27 UTC 2007




wie könnte ich nun ......

Martin

[rhabarber1848]

Nun habe ich mir ein binary für den ppc besorgt . Leif natürlich wegen dem ganzen lib gequarke nicht.

Probier bitte mal diese Datei: http://www.xup.in/dl,19192712/top/

[MPC823]

Danke @rhabarber1848 , habs eben mal probiert aber da ist halt das Problem mit dem libs

./top: error while loading shared libraries: libncurses.so.5: cannot open shared
object file: No such file or directory

Dein top

martin@MacMini:~/sourcecodes/toptest$ ldd top
libncurses.so.5 => /lib/libncurses.so.5 (0x0ff92000)
libgcc_s_nof.so.1 => not found
libc.so.6 => /lib/tls/libc.so.6 (0x0fe1e000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x0fdfa000)
/lib/ld.so.1 (0x30000000)

Gruss Martin

[rhabarber1848]

libgcc_s_nof.so.1 => not found

Bitte sehr: http://www.xup.in/dl,33444630/libgcc_s_nof.so.1/

[MPC823]

danke für Deine Hilfe



Dein binary ist aber auch dynamisch gelinkt und mir fehlen deine ganzen libs in meinem verzeichnis /lib

Ich habe das nur aufm MAC mit ldd mir anzeigen lassen welche libs überhaupt verwendet werden von der "top" version. Warum ldd dann noch anzeigt

libgcc_s_nof.so.1 => not found

weiss ich nicht

mir fehlt die

libncurses.so.5 , libgcc_s_nof.so.1 (hab ich ja nun )

Die libs libc.so.6 und libdl.so.2 habe ich in "/lib" ja sind aber in Deinem Binary nach "/lib/tls" verlinkt und das Verzeichnis habe ich ja nicht.

So der überflieger bin ich leider nicht eher "Mühsam ernährt sich das Eichhörnchen "

Ich vermute mal deswegen rennt es bei mir auch nicht

Gruss Martin

[rhabarber1848]

danke für Deine Hilfe
Dein binary ist aber auch dynamisch gelinkt und mir fehlen deine ganzen libs in meinem verzeichnis /lib

Nächster Versuch: http://www.xup.in/dl,12472396/top.tar.bz2/

[MPC823]

Leider hat es nicht geklappt

Ich habe mir nun ( für meine Verhältnisse ) ein Loch ins Knie gebohrt damit alle libs drin sind und an der richtigen stelle. Nun kommt

/tmp # ./top
./top: relocation error: /lib/libncurses.so.5: symbol cfgetospeed, version GLIBC
_2.0 not defined in file libc.so.6 with link time reference
/tmp #

Ich denke mal man muss procps innerhalb der Dbox2 Umgebung bauen. Weiss jemand oder kann mir jemand sagen wie ich die sourcen von procps im dbox_cdk direkt bauen kann ?


Gruss Martin

[rhabarber1848]

wie ich die sourcen von procps im dbox_cdk direkt bauen kann ?

make procps

[dwilx]

Ist top & co nicht schon in busybox?

[MPC823]

Ähm also gut dann kommt es doch noch raus das ich da nicht ganz durchblick.

@rhabarber1848
In meinem CDK sind keine sourcen des procps drin ich vermute mal das deswegen ein "make procps" nicht funktioniert. Wenn ich die sourcen dahin kopiere wirds wohl auch nicht viel bringen da der make file der dabei ist nicht für eine cross umgebung ist und ein configure gibts da nicht weil man das procps wohl immer Haupsächlich auf der Maschine baut für die es auch bestimmt ist. Irgendwie wirds wohl schon gehen schaun ma mal.

@dixidix
Ja in der Busybox istd as auch drin aber eine sehr ausgedünnte version wo man keine CPU Last sieht und wo man wie vorhergehend sieht man 200% Speicherverbrauch hat.


Martin

[seife]

bei newmake sind Regeln für procps drin.

Mach doch mal "make procps", dann wirst du schon sehen ;-)

Dann noch ein root-neutrino-local.sh im customization-Verzeichnis, das folgendes macht:

Code: Alles auswählen

#!/bin/sh
echo running $0

for i in top ps strace; do
        cp -a $1/../cdkroot/bin/$i $1/root-neutrino/bin/ # kopiert's ins flashroot
        rm $1/root/bin/$i # löscht das evtl. busybox-pendant (link)
done

Damit habe ich dann ein "ordentliches" top und ps im Image.

Konfiguriert wird mein CDK übrigens mit

Code: Alles auswählen

#!/bin/sh
TOPDIR=$(dirname $(pwd)) # ein Verzeichnis hoch
./configure --enable-maintainer-mode \
            --with-cvsdir=$TOPDIR \
            --prefix=$TOPDIR/root \
            --enable-flashrules \
            --with-checkiImage=rename \
            --with-rootpartitionsize=0x5A0000 \
            --with-customizationsdir=~/tuxbox/custom \
            --with-ucodesdir=~/tuxbox/ucodes \
            --with-logosdir=~/tuxbox/logos \
            --enable-ccache \
            --enable-kernel26

Wenn du die "--with-*prefix"-Optionen benutzt, dann musst du evtl. das customization-Skript anpassen.

[dwilx]

Also Regeln sind da schon drin, wenn ich das richtig gelesen habe, also make procps müsste passen, aber fürs Image fehlen wohl die Regeln wie make flash-procps.

[MPC823]

Also wenn ich make procps mache passiert bei mir rein gar nichts. Ich habe aber auf Barfs Seite gelesen das die procps irgendwie zu yadd-none gehöhren. Dann habe ich make yadd-none gebaut und die procps tools waren da. Dann noch das script von Seife rein damit ichs nicht von Hand einkopieren muss und ein neues image gebaut und warum auch immer geht es nun. Ich wundere mich nur ein bischen weil wenn ich das gebaute binary ins alte image kopiert hatte gings auch nicht. Irgendwie schon alles geheimnisvoll wenn man nicht den vollen Durchblick hat. Da ich nun ein "top-Image" habe kann ich das mal auf der avias probieren. Ich sage dann nacher mal Bescheid. Ich hoffe das wir dem Bug auf der Spur sind


Gruss Martin und Danke an alle für eure Geduld

[MPC823]

Also erst mal Vorweg es ist gar nicht so einfach da was vernünftiges Herauszubekommen.

Wenn man auf einer Nokia AVIA600er Box auf ARD ASTRA ist und liest mal den complete flash without loader aus dann dauert das 9 Sekunden , mache ich das ganze auf dem Hotbird Transponder dauert es gerade mal noch 6 Sekunden. Da merkt man schon wie träge die Box wird.

Anbei habe ich nun mal ein zwei logs mit der Ausgabe von Top AVIA 500/600 . Beim Avia 500 ist das nur reine Aufnahme und bei der 600er ist der start ohne aufnahme dann startet eine Aufnahme und dann wird die Aufnahme gestoppt. Verdammt zäh man kann es fast nicht mehr bedienen.

http://www.xup.in/dl,22850227/top_log.rar/

Vielleicht sieht man ja was.

Martin


P.S Danke an euch alle für die Hilfe

[MPC823]

Was ich auch sehe in top ist das da ein Zombie Prozess läuft

6443 root 15 0 816 816 656 R 16.8 2.6 0:23.27 top
6716 root 9 0 0 0 0 Z 1.9 0.0 0:00.07 sh <defunct>
5159 root 9 0 5768 4956 2476 S 0.6 16.0 0:10.50 neutrino
3 root 19 19 0 0 0 S 0.3 0.0 0:38.98 ksoftirqd_CPU0
1 root 9 0 476 472 444 S 0.0 1.5 0:11.21 init
2 root 9 0 0 0 0 S 0.0 0.0 0:02.09 keventd
-----------------------------------------------------------------


6443 root 16 0 816 816 656 R 14.9 2.6 0:29.43 top
6788 root 9 0 0 0 0 Z 1.9 0.0 0:00.07 sh <defunct>
5159 root 9 0 5768 4956 2476 S 1.1 16.0 0:10.88 neutrino
1 root 9 0 476 472 444 S 0.0 1.5 0:11.22 init
2 root 9 0 0 0 0 S 0.0 0.0 0:02.09 keventd
3 root 19 19 0 0 0 R 0.0 0.0 0:39.01 ksoftirqd_CPU0

Die pid von <defunct> wechselt auch ständig

Martin

[MPC823]

Da die logs nicht so ergiebieg sind wie man ich mir das Vorstellte hat da jemand noch eine bessere Idee ?


Martin

[seife]

Die Zombies kommen daher, dass irgendwas bei dir ständig eine shell forkt (wofür auch immer), die sich dann bald wieder beendet, und so lange, bis der aufrufende Prozess die Statusinformationen (Exitcode etc) von seinem "Kind" abgeholt hat (mittels wait() oder waitpid()), so lange hängt das Kind als Zombie rum.

Nun ist es nicht wirklich schwierig rauszufinden, was die shell geforkt hat:

Mit "ps -fA | grep zombie" kannst du die PPID (die PID des Vaterprozesses) rausfinden und dem mal zu Leibe rücken. Sieht dann so aus (mit telnet anstelle zombie, weil ich keine Zombies in meiner Box dulde ;-)):

Code: Alles auswählen

/var $ ps -fA|grep telnet
root       366   275  0 Jun29 ?        00:00:00 telnetd
root      2488   275  0 19:42 ?        00:00:00 telnetd
root      2527  2489  0 20:20 pts/1    00:00:00 grep telnet
/var $ ps 275
  PID TTY      STAT   TIME COMMAND
  275 ?        Ss     0:00 /sbin/inetd

In meinem Fall wurde der telnetd also von PID 275 gestartet, und die gehört dem inetd.

Das "ps -fA | grep zombie" wirst du ein paar mal wiederholen müssen, weil es vermutlich Glückssache sein wird, den Zombie gerade mal zu erwischen.