yaVDR bleibt sporadisch nach "rebootPowerOff-kernel" beim wiederhochfahren haengen

ohosch · June 15, 2012 at 9:33 AM

Hallo,

der yaVDR von Freunden hat ein sonderbares, sporadisches Fehlverhalten beim hochfahren.

Um den NVRAM Wakeup sauber hin zu bekommen musste ich die "rebootPowerOff-kernel" verwenden.

Jetzt passiert es alle X Systemstarts, das der Rechner angeht, ein Fernsehbild (Standbild) und den Mousepointer zeigt, aber weiter nichts tut.
Ich kann nicht sagen ob das Bild akutuell ist, oder aus einem Buffer zur Zeit des Power Off kommt.
Der Rechner reagiert auf keine Eingabe, und ist auch nicht per ssh nicht mehr zu erreichen. (Ping geht auch nicht, das System scheint total gecrashed zu sein).

Aus dem Syslog ist auch kaum etwas was zu erkennen:

Code

May  9 21:15:38 VDR-PC kernel: imklog 4.6.4, log source = /proc/kmsg started.
May  9 21:15:38 VDR-PC rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="980" x-info="http://www.rsyslog.com"] (re)start
May  9 21:15:38 VDR-PC rsyslogd: rsyslogd's groupid changed to 103
May  9 21:15:38 VDR-PC rsyslogd: rsyslogd's userid changed to 101
May  9 21:15:38 VDR-PC rsyslogd-2039: Could no open output pipe '/dev/xconsole' [try http://www.rsyslog.com/e/2039 ]
May  9 21:15:38 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpuset
May  9 21:15:38 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpu
May  9 21:15:38 VDR-PC kernel: [	0.000000] Linux version 2.6.38-13-generic (buildd@allspice) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #55-Ubuntu SMP Tue Jan 24 15:34:24 UTC 2012 
(Ubuntu 2.6.38-13.55-generic 2.6.38.8)
May  9 21:15:38 VDR-PC kernel: [	0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-13-generic root=UUID=19d3d73d-219a-4f9a-92d5-de065a22ae81 ro vmalloc=256m quiet splash vga=792 noresume nohz=off acpi_enforce_resources=lax vt.handoff=7
May  9 21:15:38 VDR-PC kernel: [	0.000000] BIOS-provided physical RAM map:
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000100000 - 000000007fef0000 (usable)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef0000 - 000000007fef3000 (ACPI NVS)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef3000 - 000000007ff00000 (ACPI data)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
May  9 21:15:38 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
May  9 21:15:38 VDR-PC kernel: [	0.000000] NX (Execute Disable) protection: active
May  9 21:15:38 VDR-PC kernel: [	0.000000] DMI 2.5 present.
May  9 21:15:38 VDR-PC kernel: [	0.000000] DMI: Shuttle Inc SN68PT/FN68PT, BIOS 6.00 PG 07/29/2008
May  9 21:15:38 VDR-PC kernel: [	0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
May  9 21:15:38 VDR-PC kernel: [	0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
May  9 21:15:38 VDR-PC kernel: [	0.000000] No AGP bridge found
May  9 21:15:38 VDR-PC kernel: [	0.000000] last_pfn = 0x7fef0 max_arch_pfn = 0x400000000
May  9 21:15:38 VDR-PC kernel: [	0.000000] MTRR default type: uncachable
May  9 21:15:38 VDR-PC kernel: [	0.000000] MTRR fixed ranges enabled:
May  9 21:15:38 VDR-PC kernel: [	0.000000]   00000-9FFFF write-back
May  9 21:15:38 VDR-PC kernel: [	0.000000]   A0000-BFFFF uncachable
May  9 21:15:38 VDR-PC kernel: [	0.000000]   C0000-C7FFF write-protect
May  9 21:15:38 VDR-PC kernel: [	0.000000
May  9 21:18:28 VDR-PC kernel: imklog 4.6.4, log source = /proc/kmsg started.

Display More

An dieser Stelle hoert er auf zu loggen......

Ich habe ein System updade mit
apt-get update
apt-get dist-upgrade
gemacht, aber das hat an den Symptomen nichts veraendert.
Das log ist von vor dem update. Danach hatte ich nich keinen Zugang zu dem Rechner. Ich denke aber das sich hier auch nichts veraendert hat.

Hat schon jemand sowas gesehen?

Viele Gruesse
Ohosch

fnu · June 15, 2012 at 11:11 AM

@ghosch

Mal offen gefragt, warum der uralte Mist nvram-wakeup? Was spricht gegen acpi-wakeup?

Ich sprech jetzt nur mal für mich persönlich, es wäre mir schon peinlich, wenn ich wüßte mein VDR muß beim Shutdown nochmal mit einem steinzeitlichen Kernel anbooten, nur damit er wieder aufwacht. Und das bei einem modernen SandyBridge System ...

Seit 2003 habe ich niemals etwas anderes verwendet als "acpi-wakeup". In den Jahren gab es ein oder zwei Mainboards die damit nicht wollten, die gingen dann eben wieder zurück zum Versender ...

Regards
fnu

ohosch · June 15, 2012 at 11:33 AM

Hi fnu,

vielleicht versuche ich es noch mal mit acpi wakeup, aber ich glaube, das hatte ich dem Board schon mal getan, und bin gescheitert.
Bis jetzt bin ich mit nvram-wakeup immer ganz gut gefahren. Das hier der Reboot Kernel-Poweroff noetig ist nervt gewaltig, aber viel schlimmer ist, das er jedes xte mal haengen bleibt......

Mainboard tauschen ist hier keine Option. Das ist ein Schutle Barbone, der so laufen soll wie er ist.

Viele gruesse
Ohosch

fnu · June 15, 2012 at 11:56 AM

Quote from ohosch

aber viel schlimmer ist, das er jedes xte mal haengen bleibt......

Irgendwie wundere ich mich da nicht, der Reboot Kernel ist ein Asbach® altes Ding und Du hast quasi ein brandneues SandyBridge System.

Wieviele Threads hast hier gelesen, das acpi-wakeup nicht funktioniert? Wieviele im Gegenzug, das nvram-wakeup Zicken macht?

Regards
fnu

ohosch · June 15, 2012 at 12:04 PM

Quote from fnu

Irgendwie wundere ich mich da nicht, der Reboot Kernel ist ein Asbach® altes Ding und Du hast quasi ein brandneues SandyBridge System.

Ahm, wie kommst Du darauf, das mein System ein Sandy Bridge ist? Ich habe zwar einen VDR mit Sandy Bridge, der auch super mit ACPI-Wakeup tut, aber das ist nicht der von meinen Freunden.

Das ist ein ca. 3 bis 4 Jahre altes AMD Athlon System......

Der Crash passiert auch nicht beim Reboot, sondern beim wiedereinschalten. (Hatte ich vorher nicht expliziet geschrieben)

Viele Gruesse
Ohosch

fnu · June 15, 2012 at 12:11 PM

Quote from ohosch

Ahm, wie kommst Du darauf, das mein System ein Sandy Bridge ist?

Oops, schlampig Deine Signatur gelesen ...

Quote from ohosch

Das ist ein ca. 3 bis 4 Jahre altes AMD Athlon System......

Ah, ok, bei Athlon System muß man in der Mehrheit der Fälle "HPET" für acpi-wakeup deaktivieren. Ich mach das immer bei allen AMD Boards, im BIOS und auch in Linux, durch Übergabe per "grub" ein

Code

hpet=disable

Regards
fnu

PS.: Und der Reboot-Kernel ist trotzdem Asbach® ...

ohosch · June 15, 2012 at 12:13 PM

OK, thx. Das probiere ich dann mal aus.
Ich hoffe ich komme in den naechsten Tagen an den VDR ran.

Viele Gruesse und ein schoenes Wochenende
Ohosch

ohosch · June 20, 2012 at 7:54 AM

Hallo fnu,

so, ich glaube ich habe ACPI-Wakeup zum laufen gebracht. Leider gibt es immer noch sporadische Crashed beim start, jetzt aber erst mal meine
Erfahrungen mit dem acpi-wakeup tuning. Die bestehenden Probleme mit dem System Start poste ich dahinter.

Der Rechner: Shuttle Inc SN68PT, Mainboard: FN68PT, BIOS 6.00 vom 07/29/2008

Ich weiss jetzt gar nicht welche Anteile meiner Aenderungen zum Erfolg gefuehrt haben, aber ich glaube die wichtigesten anteile hatten

1.) hpet disablen
per GRUB_CMDLINE_LINUX_DEFAULT="hpet=disabled" in /etc/default/grub (danach aufrufen: update-grub)
Natuerlich per yavdr template.
(Im Bios gabs dazu keine Einstellungen)

2.) Wakeup on Time Alarm in BIOS abstellen.

Dazu habe ich noch:

3.) in /etc/init/hwclock-save.conf "hwclock --systohc" zusätzlich den Parameter "--directisa" mitgegeben

4.) in der /etc/default/rcS HWCLOCKACCESS=no gesetzt. Hier sollte auch UTC=yes gesetzt sein.

Gelernt habe ich, das bei der Ausgabe von:

Code

cat /proc/driver/rtc

es essential ist, dass

Code

alarm_IRQ   	: yes

zu sehen ist. Sonst wacht der Rechner garantiert nicht auf.
So kann man schnell testen, ohne immer auf einen wakeup zu warten.

ohosch · June 20, 2012 at 8:02 AM

Hallo,

mein Urspruengliches Problem ist leider trotz des Umstieges von NVRAM-wakeup mit reboot Kernel auf ACPI-wakeup noch da.

Hier noch mal ein aktueller System Start mit crash

/var/log/syslog

Code

Jun 20 01:55:42 VDR-PC kernel: imklog 4.6.4, log source = /proc/kmsg started.
Jun 20 01:55:42 VDR-PC rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1068" x-info="http://www.rsyslog.com"] (re)start
Jun 20 01:55:43 VDR-PC rsyslogd: rsyslogd's groupid changed to 103
Jun 20 01:55:43 VDR-PC rsyslogd: rsyslogd's userid changed to 101
Jun 20 01:55:42 VDR-PC rsyslogd-2039: Could no open output pipe '/dev/xconsole' [try http://www.rsyslog.com/e/2039 ]
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpuset
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpu
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] Linux version 2.6.38-15-generic (buildd@batsu) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #60-Ubuntu SMP Tue May 22 11:28:40 UTC 2012 (Ubuntu 2.6.38-15.60-generic 2.6.38.8)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-15-generic root=UUID=19d3d73d-219a-4f9a-92d5-de065a22ae81 ro vmalloc=256m quiet splash vga=792 noresume nohz=off acpi_enforce_resources=lax hpet=disabled vt.handoff=7
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] BIOS-provided physical RAM map:
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000100000 - 000000007fef0000 (usable)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef0000 - 000000007fef3000 (ACPI NVS)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef3000 - 000000007ff00000 (ACPI data)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] NX (Execute Disable) protection: active
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] DMI 2.5 present.
Jun 20 01:55:43 VDR-PC kernel: [	0.000000] DMI: Shuttle Inc SN68PT/FN68PT, BIOS 6.00 PG 07/29/2008
Jun 20 01:55:43 VDR-PC kernel: [	0.00000
*****hier ist der crash******
Jun 20 06:27:23 VDR-PC kernel: imklog 4.6.4, log source = /proc/kmsg started.

Display More

Ein normaler Systemstart sieht dagegen so aus: (ich poste nur den Anfang, der ueber die Zeilen des Crash hinaus geht)

Code

Jun 20 06:27:23 VDR-PC kernel: imklog 4.6.4, log source = /proc/kmsg started.
Jun 20 06:27:23 VDR-PC rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="1033" x-info="http://www.rsyslog.com"] (re)start
Jun 20 06:27:23 VDR-PC rsyslogd: rsyslogd's groupid changed to 103
Jun 20 06:27:23 VDR-PC rsyslogd: rsyslogd's userid changed to 101
Jun 20 06:27:23 VDR-PC rsyslogd-2039: Could no open output pipe '/dev/xconsole' [try http://www.rsyslog.com/e/2039 ]
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpuset
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] Initializing cgroup subsys cpu
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] Linux version 2.6.38-15-generic (buildd@batsu) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) ) #60-Ubuntu SMP Tue May 22 11:28:40 UTC 2012 (Ubuntu 2.6.38-15.60-generic 2.6.38.8)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-15-generic root=UUID=19d3d73d-219a-4f9a-92d5-de065a22ae81 ro vmalloc=256m quiet splash vga=792 noresume nohz=off acpi_enforce_resources=lax hpet=disabled vt.handoff=7
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] BIOS-provided physical RAM map:
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 0000000000100000 - 000000007fef0000 (usable)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef0000 - 000000007fef3000 (ACPI NVS)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 000000007fef3000 - 000000007ff00000 (ACPI data)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] NX (Execute Disable) protection: active
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] DMI 2.5 present.
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] DMI: Shuttle Inc SN68PT/FN68PT, BIOS 6.00 PG 07/29/2008
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] No AGP bridge found
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] last_pfn = 0x7fef0 max_arch_pfn = 0x400000000
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] MTRR default type: uncachable
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] MTRR fixed ranges enabled:
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   00000-9FFFF write-back
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   A0000-BFFFF uncachable
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   C0000-C7FFF write-protect
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   C8000-FFFFF uncachable
Jun 20 06:27:23 VDR-PC kernel: [	0.000000] MTRR variable ranges enabled:
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   0 base 0000000000 mask FF80000000 write-back
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   1 disabled
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   2 disabled
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   3 disabled
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   4 disabled
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   5 disabled
Jun 20 06:27:23 VDR-PC kernel: [	0.000000]   6 disabled

Display More

Hat jemand eine Idee woran das liegen kann? Muss ich was im BIOS umstellen, dem Grub was anderes mitgeben, oder habe ich einen HW Defekt?

Viele Gruesse
Ohosch

fnu · June 20, 2012 at 9:34 AM

Quote from ohosch

(Im Bios gabs dazu keine Einstellungen)

Kommt sehr selten vor, aber ja warum nicht ...

Quote from ohosch

2.) Wakeup on Time Alarm in BIOS abstellen.

Grundregel für ACPI Wakeup seit je her, also viele Jahre

Quote from ohosch

3.) in /etc/init/hwclock-save.conf "hwclock --systohc" zusätzlich den Parameter "--directisa" mitgegeben

4.) in der /etc/default/rcS HWCLOCKACCESS=no gesetzt. Hier sollte auch UTC=yes gesetzt sein

Das verstehe ich nicht, hat's ohne nicht funktioniert? Oder hast Du es gesetzt weil es im vdr-wiki so stand? UTC ist klar und richtig, ebenso Pflicht

Quote from ohosch

Hat jemand eine Idee woran das liegen kann? Muss ich was im BIOS umstellen, dem Grub was anderes mitgeben, oder habe ich einen HW Defekt?

Mal andersrum gefragt, hat es jemals keinen Crash gegeben? Wenn ja wann, was hat sich seither geändert?

Regards
fnu

ohosch · June 20, 2012 at 10:50 AM

Hi Fnu,

Quote from fnu

Das verstehe ich nicht, hat's ohne nicht funktioniert? Oder hast Du es gesetzt weil es im vdr-wiki so stand? UTC ist klar und richtig, ebenso Pflicht ;

Ich hatte den GRUB eintrag zuerst nicht als template gemacht. Irgendwann
ist mir aufgefallen, das hpet=disabled gar nicht mit im Grub uebergeben
wird.

Zu dem Zeitpunkt hatte ich schon
/etc/init/hwclock-save.conf "hwclock --systohc" zusätzlich den Parameter "--directisa" mitgegeben
/etc/default/rcS HWCLOCKACCESS=no
durch den Tip im Wiki versucht.

Nachdem ich dann den GRUB eintrag korrigiert hatte tat es dann. Die beiden Eintraege habe also zumindest nicht gestoert ;).

Quote from fnu

Mal andersrum gefragt, hat es jemals keinen Crash gegeben? Wenn ja wann, was hat sich seither geändert?

Frueher ist der Rechner bei mit als reiner Client gelaufen. Da war kein automatisches Aufwachen noetig. Beim per Hand Einschalten ist mir so ein Crash nie aufgefallen.
Nun ist das Teil bei Freunden als Standalone VDR gelandet. Da muss er natuerlich zum Aufnehmen aufwachen. (seitdem fallen die Crashes auf, sind auch nur beim automatischen Aufwachen aufgefallen)
Ich habe gerade mal remote ca. 20x per Reboot per ssh gestartet. Da scheint der Crash auch nicht aufzutretetn.......

Ich bin ein wenig ratlos.

Viele Gruesse
Ohosch

fnu · June 20, 2012 at 11:00 AM

Quote from ohosch

Nachdem ich dann den GRUB eintrag korrigiert hatte tat es dann. Die beiden Eintraege habe also zumindest nicht gestoert ;).

Wenn Du nicht genau weißt was Du da tust, raus nehmen. Diese Tips sind ur-alt und für Boards, die bei ACPI Wakeup Schwierigkeiten machten ... vor 10 Jahren oder so ...

Quote from ohosch

Beim per Hand Einschalten ist mir so ein Crash nie aufgefallen.

Hmm, wo ist der Unterschied zum BIOS Wakeup? Du machst hier aber kein S3, oder? War vorher was anderes als yaVDR 0.4 drauf?

Quote from ohosch

Ich habe gerade mal remote ca. 20x per Reboot per ssh gestartet. Da scheint der Crash auch nicht aufzutretetn.......

Ohne konkreten Fehler wird man die Ursache vmtl. nie finden. Hier heißt es testen und probieren oder die HW Kombination durchwechseln bzw. fällt mir ein, eine Änderung gab es, oder?

Du hast jetzt eine DVB Karte drin und bei Dir vorher nicht?

Regards
fnu

vdrchuck · June 20, 2012 at 2:09 PM

Ist zwar keine Lösung für dein Problem, aber evtl ein Workarround.......

Übergebe per "grub" ein:

Code

panic=xx

xx= Zeit in Sekunden für ein Reboot nach einem Kernelcrash.
Wie ich es verstanden habe kommt dein Kernelcrash sporadisch und nicht bei jedem Reboot.

Gruß,
Chuck

ohosch · June 20, 2012 at 2:20 PM

chuck,
das hoert sich sehr vielversprechend an :). Vielen dank fuer den Tip.
Das stoerende ist, das sich der Rechner nach dem Crash aufhaengt, und dann nichts mehr macht. Wenn ich ihn so dazu bewegen koennte nach XX Sekunden zu rebooten wuerden die crashes zumindest nicht mehr stoeren, da der Rechner beim 2ten Versuch hoechstwahrscheinlich hoch faehrt.

fnu
Wenn ich es so recht ueberlege koennte es sein, dass der VDR vor dem Umzug zu meinen Nachbarn auf yaVDR0.3 gelaufen ist. Damit haetten wir eine gravierende Aenderung ;). Auch hat er eine neue DVB-S2 Karte bekommen, daran glaube ich aber nicht das es liegt.

Vielleicht habe ich ja jetzt einen zufriedenstellenden Workaround. :).

Ich melde mich, obs hilft.

Viele Gruesse
Ohosch

ohosch · June 20, 2012 at 2:37 PM

chuck,

mir kommen gerade leichte Bedenken, ob das mit dem Panik timer klappt.
Im syslog wird ja zumindest keine Kernel Panik gelogged.

Ich hoffe es wirkt trotzdem :). Ich habe in der naechsten Stunde 4 timer-neustarts gesetzt. Ob ich einen Crash erlebt habe sehe ich ja im Syslog.

Viele Gruesse
Ohosch

fnu · June 20, 2012 at 2:49 PM

Quote from ohosch

Auch hat er eine neue DVB-S2 Karte bekommen, daran glaube ich aber nicht das es liegt.

Aber ich könnte mir genau das vorstellen, mit der DVB-S2 Karte ...

Was ist das für eine Karte? Kann man evtl. mal einen anderen Slot probieren ... ?

Regards
fnu

zebulon · June 20, 2012 at 3:39 PM

ich habe genau dasselbe Phänomen (Mauszeiger auf schwarzem Bild), betreibe yavdr allerdings als reinen Client ohne TV-Karte mit Stremdev.

Im Log findet sich nichts, ich habe eher den Eindruck, daß er sein (per NFS eingehängtes) Videoverzeichnis manchmal nicht findet.

Entweder startet VDR manchmal schneller als das Netzwerk verfügbar ist oder ich bin zu blöd für NFS - dann sollts allerdings

überhaupt nicht gehen - und nicht nur jedes 2. Mal

Ich verfolge mal gespannt den Thread.

fnu · June 20, 2012 at 3:45 PM

Quote from zebulon

Im Log findet sich nichts, ich habe eher den Eindruck, daß er sein (per NFS eingehängtes) Videoverzeichnis manchmal nicht findet.

Ne, er hat ein anderes Problem und kommt gar nicht soweit wie Du ...

Guck oben in den syslog Auszug, bleibt direkt am Anfang des Kernel-Loading hängen ...

Regards
fnu

ohosch · June 21, 2012 at 7:59 AM

fnu

Quote from fnu

Was ist das für eine Karte? Kann man evtl. mal einen anderen Slot probieren ... ?

Die Karte ist eine TeVii S464 V2.0 (neu) DVB-S2 HDTV PCI Diseqc 1.2/2.0 Low profile
Ein anderer PCI Slot ist leider nicht mehr verfuegbar. Das Teil hat nur einen PCI und einen PCIx Slot. Der PCIx Slot ist von einer zusaetzlichen Nvidia Grafikkarte belegt. Die onBoard Nvidia beibt ungenutzt, da sie bei HD Ausgabe schwaechelt.

zebulon
wie fnu schon schrieb, ist mein Problem ein anderes. Das mit dem Mouse Zeiger und Freeze Bild war nur mit dem Reboot Kernel. Jetzt bleibt das Bild einfach schwarz (sporadisch).
Ich hoffe mal, dass ich das Problem mit dem Panic Timer egalisieren kann.

Viele Gruesse
Ohosch

fnu · June 21, 2012 at 9:39 AM

ohosch

Ich tippe immer noch auf die DVB Karte, in Verbindung mit diesem Mainboard. Du hattest vorher kein drin und das Ding lief, nun hast Du sporadisch Probleme, die aussehen als ob der Kernel Panic'd, weil er Geräte wie auch immer geartet nicht ansprechen kann. Den Wechsel von 0.3 nach 0.4 würde ich fast ausschließen, da der Sprung von Kernel 2.6.32 nach 2.6.38 nicht so groß ist ...

Allerdings gäbe es für diese Art Fehler kaum eine andere Lösung als die Kombination zu ändern und es wäre nicht das erste Mal, das so was vorkommt ...

Regards
fnu

Participate now!