.ts umwandeln nach .vdr oder PES

Moin,
leider passiert der Boot hang wenn nur ein SATA disk (an ein 3G Anschluss) und kein DVD LW angeschlossen ist.

Wenn nichts anderes dann nach mein Urlaub muss der Mainboard weg und ein andere rein.
Kernel update werde ich auch probieren. Im kernel bugtracker habe ich kein Bug gefunden der
in diese richtung geht.

Oder es gibt ein Kernel parm der vielleicht helfen könnte.

MfG

Hä??? :blink: Ist das "debianisch"? :blink:

Komisch.........:o

Ich bin schon irgendwie am verzweifeln, für ein VDR ist das 100% funtionieren vom
ausschalten und dann wieder einschalten lebensnotwendig.
Das problem ist wenn die Kiste nicht hochkommt dann sitzt es da,
im gründe bis power einmal weg ist (und wie oft passiert das), oder bis ich wieder da bin.
Ich merke irgendwann das es kaputt ist, normal sendet es mir immer emails beim start, beim shutdown, beim recording usw. Aber wenn es mal hakt, von entfernt kann ich gar nichts ausrichten. Nichtmals neu starten, obwohl das über mein Router und ein IP steuerbares steckdosenleiste
möglich wäre.

Wieso sollte ich mich dieses gefahr aussetzen. Mein alten VDR boards waren immer
100% zuverlässig. Mal gab es ein DVB treiber abstürz, aber danach lief alles wieder.

Lieber wäre es mir wenn ich diese Mainboard zum laufen bringe, aber wie lange sollte
ich noch probieren?

Hi bjd,

ich hatte auch schon extreme Probleme mit einem Asrock-MB (H67-M) mit G620 CPU und nVidia GT520.
Dieser H67 Chipsatz ist ja auch auf deinem Asus MB verbaut.

Das Hauptproblem war bei mir ein nicht sauber funktionierendes IRQ-Sharing zwischen GraKa, Netzwerk-Chip und USB-Controller.
Die GT520 GraKas waren da ganz besonders sensibel.
Ich hatte eine Asus und eine von Zotac getestet.
Die Zotac verhielt sich noch stabiler als die Asus.
Mit der Asus GT520 hat sich das System abgeschaltet sobald das LiveTV-Bild zu sehen war.
Manchmal ist das System aber garn nicht bis zum vdr durchgebootet sondern hat sich bereits vorher abgeschaltet.
Mit der Zotac und den nVidia-Treiber 295.09.07 lief das System einigermaßen stabil, hat sich aber immer noch ab und zu nach 2 - 3 Stunden einfach abgeschaltet.

Derzeit steckt eine passive GF210 von Zotac drin, mit der das System stabil läuft.
Die hat offensichtlich weniger Probleme mit dem IRQ-Sharing.

Dein System bleibt doch auch nicht immer hängen?
Poste mal einen kompletten Logsatz, wenn das System mal komplett hochgefahren ist.
Dann könnte man im Logsatz sehen, welche Geräte sich welche IRQs teilen müssen.
Evtl. hast Du ja auch so ein IRQ-Sharing-Problem.

Gruß
Klaus

Weshalb sollte die Meldung normal sein?
Bei mir kommt dieser Fehler nicht und habe ausschlieslich S-ATA Geräte.

Weshalb sollte die Meldung normal sein?
Bei mir kommt dieser Fehler nicht und habe ausschlieslich S-ATA Geräte.

Hi R2D2,

ich hab das gerade nochmal auf 7 von meinen VDRs (alle nur mit SATA-HDDs/ODDs) überprüft.
Bei allen hab ich diese Meldung.
Die Systeme laufen jedoch alle absolut stabil und ohne Probleme.
Daher meine Annahme, dass dies Meldung bei SATA-HDDs normal ist und eigentlich nicht an den Systemhängern schuld sein dürfte.

Welcher Kernel läuft eigentlich auf deinem System?
Bei mir läuft noch der unveränderte 3.0.6 der V3 Release.
Evtl. liegt es ja an der Kernel-Version, ob diese Kernel-Meldung kommt oder nicht.

Gruß
Klaus

Der aktuelle aus dem Portage natürlich. ;)

So wie übrigens auch der Rest des Systems auf dem neuesten Stand ist.

Ist das die neue Intel Chipsatz Revision? Wenn nicht, die erste hatte an den SATA 3.0 Ports Probleme, das Geräte unter Umständen nicht mehr oder nicht Korrekt erkannt wurden. Deswegen hatte Intel doch eine reisen große Rückrufaktion gestartet.
heise.de


Alternativ:
Ich hatte Problem nach einem Bios Update das ich die gen2vdr V3 nicht mehr von dem DVD-LW Booten konnte mit einem Anderen LW ging es, nach einem BIOS-Downgrade ging es auch wieder.

Also schon BIOS up- oder downgrade versucht?

Danke für diese Info!

Ich hab schon ein "B3" Asrock H67M, also die Version mit überarbeitetem Chipsatz ohne den SATA-Bug.
BIOS-Update hab ich noch keines gemacht, da ich das neuste drauf hatte.
Aber auch der überarbeitete H67 Chipsatz scheint nicht der stabilste zu sein.
Ich hätte doch ein MB mit dem abgespeckten (und neueren) H61 nehmen sollen.

Evtl. hat aber bjd ein H67 B2-MB mit dem SATA-Bug.
Sein Asus P8H67-V steht auf jeden Fall auch auf der Asus-Liste der betroffenen MBs.

Gruß
Klaus

@bbott,
Moin ist der REV3, also sollte der B3 stepping sein. Ich könnte der SATA platte
trotzdem an eine der 6G ports hängen. Kostet nix.

Und schon auf der neueste BIOS 3506 gebracht (vor ca. 2 Wochen). Problem war danach immer noch da.

MfG

@franky,
bin seit gestern mit PCI=NOMSI am testen. Seitdem kein hang.

Im moment verschärfte teste. Kiste fährt sich jeder 30 minuten hoch, nimmt 5 minuten auf und nach 5 minuten timeout, fährt sich selbst wieder runter.

Einzige andere Kernel parm was ich testen wollte wäre "ROOTDELAY=XX". Mal sehen
ob das notwendig ist oder nicht.

Welche logs brauchtest du, dmesg und everything?
MfG

Hi,

das hört sich ja gut an!
Wenn die Probleme mit PCI=NOMSI weg sind, ist ja eigentlich kein log mehr nötig.

Aber als Logs immer den kompletten Logsatz posten.
Gen2VDR sammelt da alle wichtigen logs ein und packt sie in 7z-Archiv.
Das geht entweder über das OSD (Befehle-Logs) oder mit
/_config/bin/g2v_log.sh -v

Gruß
Klaus

Moin,

und es läuft und läuft und läuft......... Und ich bin ganz glücklich

Vielen Dank für euer hilfe.

Logisch, ist ja schlieslich Gentoo und nicht Debian. :P