Fehler und gelegentlicher Absturz bei Noad

SvenS · 10. Juni 2004

Hi,

seit ich meiner Kiste einen neuen Prozessor gegönnt hab macht noad Probleme. grundsätzlich läuft es ja, aber wenn es von vdr nach dder Aufnahme automatisch aufgerufen wird stürzt der Rechner völlig kommentarlos manchmal ab. Die Abstürze sind nicht reproduzierbar, manchmal nimmt er einen ganzen tag auf und führt noad brav aus, manchmal raucht er bei der ersten bearbeiteten Aufnahme ab.

Rufe ich noad manuell, d.h. z.B. über alnewnoad auf, dann geht es einwandfrei.

Der einzige hinweis das es ein Problem geben könnte ist das im syslog:

Jun 10 07:14:58 linux-vdr noad: nice ERROR(20,0): Bad file descriptor

Kommt jedesmal wenn er anfängt zu scannen.

Ach ja aufgerufen wird noad nice -S -a -j -b -o

Hat irgendwer eine Idee woher das kommt?

bye

Sven

alex-zero · 10. Juni 2004

moin,

Bad file descriptor klingt irgendwie danach als wenn er die VDR datei nicht öffnen konnte.
Die Aufnahme ist aber in Ordnung, oder?
Schreibzugriff gibs auch unter dem User der NOAD ausführt?

Gruss
AleX

Gunnar · 10. Juni 2004

noad kann offenbar Verzeichnisse mit bestimmten Sonderzeichen im Namen nicht öffnen. Ist mir auch schon ein paar mal passiert

SvenS · 10. Juni 2004

Zitat

Original von alex-zero
moin,

Bad file descriptor klingt irgendwie danach als wenn er die VDR datei nicht öffnen konnte.
Die Aufnahme ist aber in Ordnung, oder?
Schreibzugriff gibs auch unter dem User der NOAD ausführt?

Gruss
AleX

Alles anzeigen

Hi,

Aufnahmen sind i.O. , noad läuft ja auch durch und erzeugt die marks.vdr, meistens ja auch ohne das das System einfach stehenbleibt. Auch die Rechte sind i.O.

bye

Sven

SvenS · 10. Juni 2004

Zitat

Original von Gunnar
noad kann offenbar Verzeichnisse mit bestimmten Sonderzeichen im Namen nicht öffnen. Ist mir auch schon ein paar mal passiert

welche Sonderzeichen sind das denn, schon eingekreist? Wenn ja sollen wir das thenoad mitteilen das das gefixt wird...

bye

Sven

theNoad · 10. Juni 2004

Hi.

Zitat

noad kann offenbar Verzeichnisse mit bestimmten Sonderzeichen im Namen nicht öffnen. Ist mir auch schon ein paar mal passiert

Mir noch nicht! Welche Sonderzeichen stören?

Zitat

Der einzige hinweis das es ein Problem geben könnte ist das im syslog: Jun 10 07:14:58 linux-vdr noad: nice ERROR(20,0): Bad file descriptor

Dieser Fehler tritt immer dann auf, wenn der nice-level nicht richtig gesetzt werden konnte. Ausgegeben wird der nice-level, der gesetzt werden soll (hier:20) und der tatsächlich gesetzte nice-level (hier:0). Dieser Fehler sollte allerdings seit noad-0.4.2 nicht mehr auftreten, da ich den default für nice auf 19 gesetzt habe (zulässiger miximalwert). In meinem System (Suse 8.1) wird bei nice-level 20 oder höher allerdings automatisch der höchste nice-level gesetzt, ich erhalte dann die Fehlermeldung "nice ERROR(20,19) success".
Das "Bad file descriptor" ist irrelevant, das liegt an einem Fehler in der logging-Ausgabe.

Zitat

Kommt jedesmal wenn er anfängt zu scannen.

Dann kann noad den nice-level garnicht ändern. Das kann natürlich zu einer erhöhten Systembelastung führen.

Hier ein patch für noad-0.4.2, damit wir evtl. dem Fehler mit dem nice auf die Spur kommen (diff-ähnliches format):

Code

if( bNice )
    {
      int niceErr = nice(niceLevel);
++      int oldErrno = errno;
       if( errno == EPERM || errno == EACCES )
       {
--         fprintf(stderr, "nice %d: no super-user rights\n",niceLevel);
         esyslog(LOG_ERR, "ERROR: nice %d: no super-user rights",niceLevel);
++         errno = oldErrno;
++         fprintf(stderr, "nice %d: no super-user rights\n",niceLevel);
       }
       else if( niceErr != niceLevel )
       {
--         fprintf(stderr, "%d %d %m\n",niceErr,errno);
         esyslog(LOG_ERR, "nice ERROR(%d,%d): %m",niceLevel,niceErr);
++         errno = oldErrno;
++         fprintf(stderr, "%d %d %m\n",niceErr,errno);
       }

Alles anzeigen

Zur Eingrenzung des Fehlers empfehle ich, vorrübergehend ein "-vvv" n den noad-Aufruf einzubauen. Das produziert dann zwar Unmengen an logging-Ausgaben, hilft aber vielleicht den Fehler zu finden.

Gruß
theNoad

SvenS · 10. Juni 2004

Hi,

aha, hatte in noad 0.4.2 den nice level im source auf 20 geändert.

Das logging habe ich hochgesetzt und prompt vorhin den Fehler wieder gehabt. Beim Starting ac3 check ist er abgeraucht, der letzte Eintrag im syslog war hdc lost interrupt...und nein, das Board und dessen IDE Controller kann es nicht sein, das hab ich letztes Wochenende zweimal getauscht mit dem gleichen Ergebnis :).:(

Ich hab jetzt mal den AC3 check disabled mal sehen was dann geht. Evtl liegt das Problem dort, da bei einem manuellen Aufruf mit allnewnoad ohne ac3 check selbst bei höchster Systemlast bei gut 10 Tests in den letzten Tagen nie das Problem auftauchte, immer nur wenn vdr mit -r noad aufruft.

Ich werd jetzt mal den patch anwenden, ac3 check abschalten und nice level zurücksetzen. Dann mal sehen...

bye

Sven

Gunnar · 11. Juni 2004

Zitat

Original von theNoad
... Welche Sonderzeichen stören? ...

sorry, weiß ich leider nicht mehr, aber nach umbenennen des Verzeichnisses lief es dann.
Beim nächsten Mal werd ich es notieren

Gunnar

SvenS · 11. Juni 2004

Hi,

hab heute nacht was aufnehmen lassen und noad per -r drüberlaufen lassen. Ergebnis ist:

Jun 11 06:04:08 linux-vdr noad: current Marks end
Jun 11 06:04:08 linux-vdr noad: totalFrames 78781
Jun 11 06:04:08 linux-vdr noad: totalDecodedFrames 36008
Jun 11 06:04:08 linux-vdr noad: decodedFramesForLogoDetection 546
Jun 11 06:04:08 linux-vdr noad: decodedFramesForLogoCheck 0
Jun 11 06:04:08 linux-vdr noad: decodedFramesForAC3Detection 0
Jun 11 06:04:08 linux-vdr noad: decodedFramesForAC3Check 0
Jun 11 06:04:08 linux-vdr noad: secsForLogoDetection 13
Jun 11 06:04:08 linux-vdr noad: secsForLogoCheck 0
Jun 11 06:04:08 linux-vdr noad: secsForAC3Detection 0
Jun 11 06:04:08 linux-vdr noad: secsForAC3Scan 0
Jun 11 06:04:08 linux-vdr noad: secsForScan 848
Jun 11 06:04:08 linux-vdr noad: hasBlackLines no
Jun 11 06:04:08 linux-vdr noad: hasAC3 no
Jun 11 06:04:08 linux-vdr noad: hasOverlaps no
Jun 11 06:04:08 linux-vdr noad: picSize 720x576
Jun 11 06:04:08 linux-vdr noad: noad aborted by signal Segmentation fault

Die marks.vdr ist aber einwandfrei erzeugt worden. Ach ja, die Anpassung für das Errorlogging von thenoad ist bereits drin. Werd später mal das ganze Logfile durchsuchen...

bye

Sven

tertel · 11. Juni 2004

theNoad:

soweit ich mich erinnern kann stört das Sonderzeichen ' (Hochkommata) als auch - (Minuszeichen) im Verzeichnisnamen.

Gruss
Tertel

TomG · 11. Juni 2004

Zitat

Original von theNoad

Dieser Fehler tritt immer dann auf, wenn der nice-level nicht richtig gesetzt werden konnte. Ausgegeben wird der nice-level, der gesetzt werden soll (hier:20) und der tatsächlich gesetzte nice-level (hier:0). Dieser Fehler sollte allerdings seit noad-0.4.2 nicht mehr auftreten, da ich den default für nice auf 19 gesetzt habe (zulässiger miximalwert). In meinem System (Suse 8.1) wird bei nice-level 20 oder höher allerdings automatisch der höchste nice-level gesetzt, ich erhalte dann die Fehlermeldung "nice ERROR(20,19) success".

Beim Aufruf von nice wird nicht der gewünschte nice-Level übergeben, sondern das Inkrement. Wenn der nice-Level vorher 0 war, kommt das natürlich auf das gleiche hinaus.

Superuser-Rechte werden hier nicht benötigt, die braucht man nur für einen negativen Inkrement, das heißt für die Erhöhung der Priorität des Prozesses.

Auszug aus man 2 nice:

Code

int nice(int inc);


BESCHREIBUNG
       nice  addiert inc zur Priorität des aufrufenden Prozesses.  Zu beachten
       ist, daß nur  der  Superuser  ein  negatives  Inkrement  angeben  darf.
       Intern  bedeutet eine höhere Nummer ein höhere Priorität.  Es ist nicht
       zu verwechseln mit den Prioritäten die von nice benutzt werden.

Tom

SvenS · 12. Juni 2004

Hi,

So, nach ausgiebigsten Tests, unglaublich vielen sinnlosen (inhaltlich) Aufnahmen seit gestern abend. Kann ioch jetzt davon ausgehen das das Problem behoben ist. Noad war der Auslöser, nicht die Ursache. Mein VDr läuft wieder stabil, nur der nice Fehler ist noch da, macht aber ausser dem Eintrag im log und etwas langer Laufzeit keine Probleme.

Die Lösung war einen neuen Kernel zu backen. Nach exzessivem googeln gestern bin ich darauf gestoßen, das der Kernel von Suse 8.0 (2.4.18) offenbar auf manchen Boards Probleme mit dem IDE speziell DMA bei heftigen Plattenzugriffen hat. Das deckt sich auch mit dem Fehler, denn der trat verstärkt dann auf, wenn noad lief und gleichzeitig eine Aufnahme abgespielt wurde. 'Offenbar war das Board das ich vorher drin hatte ein seltenes Exemplar mit dem der Kernel konnte, da ich danach zwei andere Boards bei denen der Fehler ebenfalls auftrat getestet hatte.

Daraufhin hab ich einen 2.4.26 Kernel mit der gleichen Konfig wie der Suse Standardkernel gebacken und siehe seitdem funktionierts. Nebenbei, der lange hier rumliegende Promise Controller (kann UDMA 100, was der onboard Controller nicht, die Platten aber schon können) kann jetzt mit diesem Kernel auch einwandfrei verwendet werden.

Der WAF ist auch gerettet, weil das ständige auf den Dachboiden steigen zum restarten war nicht so lustig und die Alternative noad zu deaktiviern auch nicht zuträglich. Na ja, der Watchdog ist schon zusammengelötet muss nur noch getestet und eingebaut werden, dann geht das auch automatisch (und wird hoffentlich nie gebraucht)

Wollte eigentlich diese Wochenende mal die 1.3.10 ausprobieren, aber jetzt geniesse ich erst mal wieder die einwandfreie Funktion

bye

Sven

REK · 24. November 2004

In welcher Datei wird noad mit den parametern automatisch aufgerufen?

Fehler und gelegentlicher Absturz bei Noad

Jetzt mitmachen!

Teilen