VDR box haengt sich manchmal bei Festplattenzugriff auf

Malden · 29. Mai 2006

Hallo,

Ich habe seit recht langer Zeit das Problem, dass sich der VDR Rechner (siehe Signatur) sporadisch aufhaengt. Die Festplatten LED bleibt konstant an, das Fernsehbild und die LCD Anzeige laeuft weiter, aber Fernbedienung reagiert nicht mehr und Power-Knopf druecked bringt auch nichts. Im normalem Fall faehrt der VDR damit sauber runter.
Das ganze passiert recht selten, so 1 mal in zwei Wochen (bei taeglichem Betrieb) und scheinbar immer wenn auf die Festplatte zugegriffen wird, oft bei Aufnahmen. Deshalb hatte ich auch die Festplatte in Verdacht.
Jetzt habe ich die Platte aber gegen eine brand neue ausgetauscht aber nach zwei Wochen wieder das gleiche Problem.

Kennt das jemand ? Wenn nicht die Festplatte die Schuldige ist, was koennte es denn sein? Koennte LinVDR 0.8 mit neuem Kernel helfen (wenn es dann rauskommt). Ich habe noch LinVDR 0.7 unverpanscht, keine Patches..

Malden

mblaster4711 · 29. Mai 2006

Schau mal was das syslog sagt.
RINGBUFFER_SYSLOG="no"
in /etc/sysconfig einfügen und neu starten,
dadurch wird das syslog in die Datei
/var/log/messages
geschrieben und ist nach einem Neustart noch vorhanden.

Malden · 30. Mai 2006

Zitat

Original von mblaster4711
Schau mal was das syslog sagt.

Danke fuer den Tip. Syslog ist jetzt eingeschaltet und nun warte ich halt bis sich die Kiste wieder aufhaengt Dann melde ich mich wieder mit dem log.
Ich hoffe, dass ich das Problem bald loesen kann, denn wenn meine Frau noch einmal ihre Lieblingsfolge verpasst, kramt sie den alten Videorecorder wieder raus

Malden.

mbruehl · 30. Mai 2006

Das hatte ich damals bei meinem unverpanschten LINVDR 0.7. auch, Abhilfe schafte ein Update der DVB-Treiber, danach war es weg.
Das Paket von damals finde ich nicht mehr, aber in den aktuellen Cody Tarandor etc. Paketen ist es scheinbar mir drin.
Falls du Angst vor einem Update hast : Meine Frau ist sehr empfindlich was den VDR angeht, 1x Aufhängen pro Woche wird maximal toleriert. Aber auch mit den aktuellen Patches geht das.....

bigbungle · 30. Mai 2006

ohhh.. wenn das "gesetz" schon so weit ist, dann wird es ernst
nichts für ungut!

heiwil · 30. Mai 2006

Den Ringbuffer abzuschalten reicht allein nicht aus. Die /var/log/messages steht dann immer noch in der /ramdisk und ist natürlich nach dem Neustart hinüber. Zwar wird der Inhalt der ramdisk beim Herunterfahren auf die Platte geschrieben, aber dazu hat Deine Kiste keine Lust mehr.
Du mußt also zusätzlich noch das Logfile auf die Platte umlenken.
Ich habe z.Zt. keinen Zugriff auf meinen vdr, habe die Verzeichnisstruktur nicht im Kopf und kann deshalb kein Kochrezept dazu geben.

Aus eigener Erfahrung und aus dem Lesen der vielen ähnlichen Beiträge hier, ist IHMO der von Dir beschriebene Fehler ein Hardwareproblem. Die üblichen Verdächtigen sind Platte, Kabel, Speicher, Netzteil.
Die Platte läßt sich mit smartctl testen, der Speicher mit memtest (ist auf jeder Linux-Live-CD enthalten), der Rest wahrscheinlich nur durch tauschen.

Heiko

s_herzog · 30. Mai 2006

Hab ich hier mit aktuellstem Tarandor/Dr.Seltsam/Cody - Pansch aber auch!

Zu dem Zeitpunkt habe ich oft mehrere noad-Läufe am Start und gelegentlich auch ne DVD compiliert, dann reagiert aber auch z.B. die bash per ssh schon träge....

Ich tippe auf swapping, hab nur 256MB und Swapspace nur in ner Swap-DATEI, also keine Partition.

Swap-Datei auf Journaling Filesystemen haben so ihre...Problemchen, wenn sie volllaufen....

Malden · 30. Mai 2006

Also fasse ich mal zusammen: wir haben jetzt drei moeglich Fehlerursachen.

1. DVB Treiber
das sollte mit kommendem Update auf LinVDR 0.8 geloest sein (will nicht panschen)

2. Hardware
Platte ist schon getauscht, Speicher werde ich testen/tauschen, Kabel und Netzteil eher unwahrscheinlich

3. Swap Datei
keine Ahnung wie man das beheben koennte, extra Partition koennte vielleicht helfen, bei LinVDR moeglich?

Wenn der VDR das naechste mal streikt, werde ich versuchen das log per ssh vor dem Ausschalten (Stecker ziehen) anzuschauen.

Danke fuer Eure Hinweise, Malden

GMO · 30. Mai 2006

Moin,

ich kann zwar nichts produktives zu dem Problem beitragen, möchte aber kurz anmerken, daß das bei mir auch schonmal aufgetreten ist. System läuft seit ca. einem Jahr unverändert im Wohnzimmer durch.

Allerdings nicht 24x7, sondern nur dann, wenn wirklich geschaut wird.

Falls das wirklich ein sich abzeichnender Hardwareschaden der Platte wäre.... übel... werde nachher mal ein Backup machen.

Ich hatte bis jetzt immer vermutet, daß ein Prozess den VDR blockiert (noad?). Da sich nach wenigen (?) Minuten das System wieder berappelt hat.

Hardwaremäßig ausschalten weil nix mehr ging musste ich in den 1,5 Jahren keine 3 mal...

Zum Thema Swapping: Hab bei mir ne eigene Swap-Partition, ca. 1GB, Hauptspeicher 512 MB, sollte für nen VDR reichen...

Ciao, Olli

theonlychriss · 30. Mai 2006

Hi,

ich hatte auch mal genau solche Probleme (Rechner tot, LED-strahlt). Da half es, von udma5/6 auf 3 runterzugehen (IDE-Controller war/ist schuld).

Viele Grüße
Chriss

mblaster4711 · 30. Mai 2006

Zitat

Original von s_herzog
Ich tippe auf swapping, hab nur 256MB und Swapspace nur in ner Swap-DATEI, also keine Partition.

Ähm, ich habe 128MB-RAM, davon 4MB Ramdisk und Swapfile=256 kByte und bei mir hängt sich nichts auf.
Natürlich ist er auch mal träge (FB/OSD oder SSH), das kommt hauptsächlich vor wenn ich im VDR-Admin das Live-Bild anschaue und gleichzeitig noch NOAD oder BURN aktiv ist.
Mein VDR läut 24/7.

Malden · 5. Juni 2006

Also hier gleich mal das Neueste zu diesem Thema:

War am Wochenende nicht zu Hause und als ich am Sonntag Abend zuruekkam, hatte sich die Kiste wieder aufgehaengt. Aber diesmal war die Festplatten LED nicht dauernd an.

Was ist passiert: am Freitag abend 5 min vor der Aufnahme hochgefahren, dann korrekt angefangen aufzunehmen, nach 40sec endet die Aufnahme (war fuer 30min programmiert). Also denke ich mir VDR oder der Treiber hat irgendein Problem. Leider sind die entsprechenden Eintraege nicht mehr im Log, da ich es erst nach zwei Tagen anschauen konnte und diese offensichtlich nach einiger Zeit ueberschrieben werden.

Im log steht alle 5min

Code

Jun  4 19:00:01 linvdr cron.notice crond[1134]: USER root pid 1702 cmd convert.pl -q -s

was darauf schliessen laesst, dass crond noch funktioniert.

Zugriff ueber ssh auf den VDR Rechner funktionierte noch. Auch Dateien kopieren ging, also liegt das Problem wahrscheinlich doch nicht an der Festplatte.

Nachdem ich den Powerknopft gedrueckt hatte, erschien das hier im log (btw: habe keine Budget Karte, nur FF)

Code

Jun  4 19:24:34 linvdr daemon.info init: ^MStarting pid 1711, console /dev/console: '/etc/init.d/rcShutdown'
Jun  4 19:24:39 linvdr user.warn kernel: saa7146: unregister extension 'budget dvb /w video in'.
Jun  4 19:24:39 linvdr user.warn kernel: saa7146: unregister extension 'budget_ci dvb'.
Jun  4 19:24:39 linvdr user.warn kernel: saa7146: unregister extension 'budget dvb'.
Jun  4 19:24:39 linvdr daemon.notice lircd 0.7.0pre4[1094]: caught signal
Jun  4 19:24:39 linvdr user.err vdr[1119]: ERROR: lircd connection lost
Jun  4 19:24:39 linvdr user.debug vdr[1119]: LIRC remote control thread ended (pid=1119, tid=5126)

Der Rechner faehrt aber nicht runter.

Ein "kill -9" des vdr Prozesses bringt nichts. Der Prozess laeuft einfach weiter.
"runvdr stop" haengt irgendwo, muss mit "ctrl C" gestoppt werden
"reboot" und "halt" fahren den Rechner nicht runter.

Was soll ich davon nun halten? Ist der VDR process oder DVB Treiber einfach nur blockiert oder hat LinVDR hier ein Problem? Hat irgendjemand 'ne gescheite Idee?

Malden · 29. September 2006

Es hat ziemlich lange gedauert aber ich habe jetzt endlich ein gutes log zu dem Problem. Es scheint sich hier um den beruechtigetn "ring buffer overflow" zu handeln.

Aber sehen wir uns das mal im Detail an. Das Ganze beginnt mit dem Start der Aufnahme:

Code

Sep 21 12:58:00 linvdr user.debug vdr[1110]: switching device 1 to channel 57
Sep 21 12:58:00 linvdr user.info vdr[1110]: timer 4 (57 1258-1331 'NICK') start
Sep 21 12:58:00 linvdr user.debug vdr[1110]: Title: 'Nickelodeon' Subtitle: '(null)'
Sep 21 12:58:00 linvdr user.info vdr[1110]: record /video0/NICK/_/2006-09-21.12.58.50.50.rec
Sep 21 12:58:00 linvdr user.debug vdr[1110]: creating directory /video0/NICK/_/2006-09-21.12.58.50.50.rec
Sep 21 12:58:00 linvdr user.debug vdr[1110]: recording to '/video0/NICK/_/2006-09-21.12.58.50.50.rec/001.vdr'
Sep 21 12:58:00 linvdr user.debug vdr[1137]: file writer thread started (pid=1137, tid=7176)
Sep 21 12:58:00 linvdr user.debug vdr[1138]: recording thread started (pid=1138, tid=8201)
Sep 21 12:58:00 linvdr user.debug vdr[1139]: receiver on device 1 thread started (pid=1139, tid=9226)
Sep 21 12:58:00 linvdr user.debug vdr[1140]: TS buffer on device 1 thread started (pid=1140, tid=10251)
Sep 21 12:58:01 linvdr user.info vdr[1110]: switching to channel 9
Sep 21 12:58:01 linvdr user.info vdr[1110]: info: Channel not available!
Sep 21 12:58:03 linvdr user.info vdr[1110]: switching to channel 57
Sep 21 12:58:03 linvdr user.debug vdr[1110]: max. latency time 3 seconds
Sep 21 12:58:03 linvdr user.debug vdr[1141]: transfer thread started (pid=1141, tid=11276)

Alles anzeigen

Nach 5 Minuten beginnen die Probleme mit dem Buffer:

Code

Sep 21 13:03:29 linvdr user.debug vdr[1139]: buffer usage: 70% (tid=8201)
Sep 21 13:03:31 linvdr user.debug vdr[1139]: buffer usage: 80% (tid=8201)
Sep 21 13:03:33 linvdr user.debug vdr[1139]: buffer usage: 90% (tid=8201)
Sep 21 13:03:34 linvdr user.debug vdr[1139]: buffer usage: 100% (tid=8201)
Sep 21 13:03:34 linvdr user.err vdr[1139]: ERROR: 1 ring buffer overflow (65 bytes dropped)
Sep 21 13:03:40 linvdr user.err vdr[1139]: ERROR: 12416 ring buffer overflows (2334208 bytes dropped)
Sep 21 13:03:46 linvdr user.err vdr[1139]: ERROR: 14179 ring buffer overflows (2665652 bytes dropped)
Sep 21 13:03:52 linvdr user.err vdr[1139]: ERROR: 11504 ring buffer overflows (2162752 bytes dropped)

und so weiter bis zum Ende der Aufnahme:

Code

Sep 21 13:31:00 linvdr user.debug vdr[1138]: recording thread ended (pid=1138, tid=8201)
Sep 21 13:31:03 linvdr user.err vdr[1110]: ERROR: thread 7176 won't end (waited 3 seconds) - cancelling it...
Sep 21 13:31:03 linvdr user.debug vdr[1110]: buffer stats: 5242879 (100%) used
Sep 21 13:31:03 linvdr user.info vdr[1110]: timer 4 (57 1258-1331 'NICK') stop

Danach faehrt die Kiste nicht mehr runter und reagiert auch nicht auf die Fernbedienung. Es sieht aus, als ob vdr abgeschmiert ist. Nur noch Stecker raus (und natuerlich wieder rein) hilft.

Hier also meine Fragen:
- ist das ein bekanntes Problem ?
- gibt es dafuer einen Fix ?
- wird LinVDR 0.8 noch dieses Problem haben ?

Es waere schoen, wenn mir damit jemand helfen koennte,
Malden

Fuselfasel · 30. September 2006

Hallo Malden,

bin froh, dass es noch jemanden gibt, der das gleiche Problem beschreibt wie ich es z.Zt. auch habe.

Ich muss aber dazu sagen, dass das VDR hängen mit HD-LED-Dauerlicht erst nach meinem FSB MHz hochsetzen von 100 auf 166MHz aufgetreten ist (dadurch wird wieder mein Original AMD Sempron 2200 mit 1,5GHz erkannt). Die RAMS habe ich gegen einen 512MB Infineon Riegel PC3200/400 CL3 ausgetauscht, das Netzteil ist noch nicht ausgetauscht. Die CPU Kühlung ist ok, mittlere Temperatur ist mit meinem HT102 ca. 45°C. Meine Samsungs SP2514 sind ca. 1 Jahr alt, werden aber gut warm. Die Slave-HD wurde per Hand gemountet, hier habe ich schon überlegt die Daten zu sichern, die Slave-Platte komplett neu über Setup zu initialisieren, mal sehen ...

Habe jetzt in /etc/sysconfig die Zeile "...RINGBUFFER_SYSLOG="no" ..." ergänzt. Werde also die Logfiles analysieren.

Mein aktuelles Problem: Wenn die HD "viele Daten bewegt" (z.B. durch Überspielen von AVI Files nach /pub/mplayer), schmiert nach einer beliebigen Zeit t mein VDR ab, von extern lässt sich der Rechner nicht mehr anpingen und Fernbedienung sowie Tastatur sind ohne Wirkung. Lediglich das zuletzt laufende Live-TV schnurrt weiter

[NACHTRAG - VDR hängt nicht mehr :strike1]:
Die Logs haben nichts verräterisches nach einem VDR-Hänger angezeigt, bis auf einige Timeouts mit einer meiner cx88's.
Ich habe daraufhin meine Onboard Netzwerkkarte (die unter VDR mit "via-rhine" eingebunden war) deaktiviert und eine linuxfreundliche Realtek 8139 reingehängt, diese wurde in der /etc/sysconfig mit "... NETWORK_DRIVER_LAN="8139too"..." eingebunden. Anschließend habe ich wieder Gigabytes an Daten auf die VDR-Festplatte überspielt und bis jetzt keinen Hänger erhalten. Lt. meiner IRQ-Verteilung shared diese NC nun unglücklicherweise mit meiner Nexus-S, aber ohne Probleme:
cat /proc/interrupts
CPU0
0: 401737 IO-APIC-edge timer
1: 252 IO-APIC-edge i8042
8: 801109 IO-APIC-edge rtc
9: 1 IO-APIC-level acpi
12: 130 IO-APIC-edge i8042
14: 76261 IO-APIC-edge ide0
15: 28 IO-APIC-edge ide1
177: 8069267 IO-APIC-level eth0, saa7146 (0)
185: 410540 IO-APIC-level cx88[0]
193: 419819 IO-APIC-level cx88[1]
NMI: 0
LOC: 401677
ERR: 0
MIS: 0

Ich werde dieses Phänomen weiter beobachten ... vielleicht hilft mein Geblubber anderen VDR'lern

[NACHTRAG 2]:
*kleinlaut*: Es besteht doch die Möglichkeit, dass die Ursache des Absturzes eher in Richtung NOAD zielt mit Problemen der Memory-Verwaltung. Details: siehe meinen nachfolgenden Kommentar..:

JK1974 · 30. September 2006

Hi,

hatte auch Hänger vor einiger Zeit mit selbstkompiliertem VDR - nach heftigem Festplattenzugriff ging nix mehr. Irgendwann hat sich herausgestellt (evtl. auch hier in alten Threads zu lesen), dass der VDR "temperaturempfindlich" war, genauer gesagt das Mainboard. Auch von einem Hersteller habe ich bestätigt bekommen, dass die VIA-Chips damals knapp mehr als 40 Grad Innentemperatur nicht verpacken und dann gerne zu Abstürzen neigen.
Kurzum: Seitdem ich in dem gleichen Gehäuse, ich glaube sogar mit einer Festplatte mehr, mit den gleichen DVB-Karten etc. ein nForce-2-Board und kein VIA-Board mehr drin habe, läuft es völlig ohne Probleme - auch bei Sonneneinstrahlung im Sommer.

Grüße

Jörg

SHF · 30. September 2006

Ich hatte Abstürze durch noad das hatte ähnliche Symptome.

Fuselfasel · 1. Oktober 2006

Ein guter Tipp SHF. Ich erlaube mir Deine Änderung mit einer zusätzlichen kurzen Anleitung zu erweitern:

linvdr: nano /usr/bin/noadcall.sh
EINFÜGEN von "MAX_SIZE":

Bash

#!/bin/sh
# this is an example-script for a noad-call with
# different parameters for a call before or after 
# a recording is done
# this script should be called from inside vdr via '-r ' 
# e.g. vdr '-r /usr/local/sbin/noadcall.sh'


MAX_SIZE=10000

Die unteren Zeilen wie folgt editieren:

Code

if [ $1 == "before" ]; then
  ulimit -v $MAX_SIZE && $NOAD $* $ONLINEMODE $ADDOPTS $BEFOREOPTS
else
  ulimit -v $MAX_SIZE && $NOAD $* $ONLINEMODE $ADDOPTS $AFTEROPTS
fi

Zum direkt testen --> VDR neustarten:

Code

linvdr:/# /etc/init.d/runvdr stop
linvdr:/# /etc/init.d/runvdr start

Jetzt mal was aufnehmen und sich mit LOGREAD -F ansehen, wie noad gestartet wird ...

Bis jetzt klappt alles gut. Der Anlass des Ganzen war bei mir ein gestriger VDR-Absturz während der nächtlichen Formel1-Aufnahme. Ein RESET war nötig. Die Logs gaben leider nichts mehr her, ABER ich konnte in /video0/noadonlinestat sehen, dass kein Eintrag für die Formel1 Aufnahme gespeichert wurde.

Eine Frage habe ich noch - wie interpretiere ich diese Fehlermeldung von NOAD?

Code

Oct  1 12:37:49 linvdr user.err noad[2459]: ERROR: can't realloc() index

Fuselfasel · 1. Oktober 2006

SHF: Ich habe ein ECHTES Problem: Der VDR schmiert mir weiterhin während der Aufnahme ab, d.h. Live-TV wird angezeigt (Bild & Ton), die Festplatten-LED leuchtet konstant, es ist kein Netzwerkzugriff möglich und die Tastatur sowie Fernbedienung haben keinen Einfluss auf den VDR mehr ...

SHF: Wie ist Dein NOAD Shell korrekt einzubinden? Das Prinzip ist mir schon klar ... ich versuche testweise mal manuelle Aufrufe ...

SHF · 1. Oktober 2006

Characteristisch für meinen Absturz waren diese Logeinträge:

Code

Jun  4 18:19:17 vdr kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jun  4 18:19:17 vdr kernel: VM: killing process noad

Und die Tatsache, dass NOAD fast den Gesamten Speicher verbraucht. Das lässt sich mit "top" kontrollieren, das Problem ist nur den richtigen Zeitpunkt zu erwischen.

Zitat

SHF: Wie ist Dein NOAD Shell korrekt einzubinden? Das Du im anderen Thread schreibst, dass es anstelle des NOAD's aufzurufen ist, kapiere ich leider nicht ...

Bei mir wurde vorher NOAD vom VDR direkt gestartet. Mein Skript ist also das Equivalent zu /usr/bin/noadcall.sh. Die entsprechenden Zeilen dort anzupassen ist also genauso gut.

Zitat

SHF: Ich habe ein ECHTES Problem: Der VDR schmiert mir weiterhin während der Aufnahme ab, d.h. Live-TV wird angezeigt (Bild & Ton), die Festplatten-LED leuchtet konstant, es ist kein Netzwerkzugriff möglich und die Tastatur sowie Fernbedienung haben keinen Einfluss auf den VDR mehr ...

Als erstes solltest du mal den NOAD-onlinemodus deaktivieren, der kann problematisch sein. Ich hab den aber noch nie probiert.
Eigentlich sollte es reichen die folgende Zeile Auszukommentieren:

Code

if [ $1 == "before" ]; then
#  ulimit -v $MAX_SIZE && $NOAD $* $ONLINEMODE $ADDOPTS $BEFOREOPTS
else
  ulimit -v $MAX_SIZE && $NOAD $* $ONLINEMODE $ADDOPTS $AFTEROPTS
fi

Fuselfasel · 1. Oktober 2006

Danke für die prompte Rückinfo. Ich kommentiere mal die Zeile zu Testzwecken aus (macht es überhaupt einen Unterschied? Noad wird in diesem Fall nur bei getimeten Aufnahmen gestartet...)

Dumm bleibt nur, dass die VDR-Störung plötzlich und unerwartet, irgendwann aus heiterem Himmel kommt - mit LOGREAD komme ich bei der Analyse bei mir nicht weiter, auch bei der permanenten Putty-Logausgabe, ist an der Stelle des Absturzes nichts Auffälliges. Ich zweifele auch noch etwas an dem Memory-Problem, ob dieser überhaupt bei mir der wahre Grund für den Absturz darstellt, mal sehen.

Ich werde noch weiter rumfummeln ...

VDR box haengt sich manchmal bei Festplattenzugriff auf

Jetzt mitmachen!

Teilen