Beiträge von RoRo

    bevor ich mir eine neue Karte kaufen würde, würde ich zumindest das BIOS der GPU einmal aktualisieren.
    Bei mir und vielen anderen brachte das den gewünschten Erfolg.


    Meinst Du denn, dass es einen Sinn ergibt, die selbe Version nochmal drüber zu flashen? Wie ich schon weiter oben schrieb, gibt es bei techpowerup zwar eine Version für meine Grafikkarte (alle IDs entsprechen meiner Karte), aber leider ist die Versionsnummer auch die selbe, wie diejenige, die bei mir (laut Xorg.1.log) schon installiert ist.
    Da auch andere Leute mit der gleichen Grafikkarte von Problemen berichteten, gehe ich mal davon aus, dass da nicht nur ein Bit in meinem VGA-BIOS gekippt ist, sondern dass die Karte einfach Murks ist.


    Bleibt also primär der Neukauf, wobei ich jetzt schon überlege, ob ich mir das Nachfolgemodell von ASUS (GT610) kaufen soll (in der Hoffnung, dass die dann länger kompatibel bleibt als die letzte), oder ob eine Zotac GT710 die bessere Wahl ist (wobei Deine Erfahrungen mit Zotac ja auch nicht viel überzeugender klangen, auch wenn Du final ja ein gutes Ergebnis erreicht hast).


    Mal schauen, ich glaube ich bleibe jetzt erstmal ein paar Wochen bei yaVDR 0.5 und freue mich, dass der jetzt wieder funktioniert (bis auf die USB-Tastatur, die musste ich im BIOS deaktivieren, weil ich seit dem BIOS-Update des Mainboards entweder kein WoL mehr hatte oder alternativ der Rechner immer 5 Sekunden nach dem Abschalten wieder automatisch aufwachte, aber das ist eine andere Baustelle. Hatte ich erwähnt, dass ich Hardware, die nicht das tut, was ich ihr sage, hasse?)


    Danke für Eure Hilfe
    Roland

    Hast du denn über das yaVDR-Webfrontend deinen Fernseher erkennen lassen und dort Auflösung und mögliche Bildwiederholraten eingestellt? Damit sollte dann die korrekte xorg.conf.yavdr mit den nötigen Optionen erstellt werden


    Dummerweise scheint das nicht zu funktionieren, denn es versucht erstmal xorg-launcher zu stoppen, was aber nicht geht, weil X ja garnicht läuft (stürzt ja ab).


    da hilft nur das Flashen einer neuen Grafikkartenfirmware. Vllt. gibt es sogar genau die passende Firmware für deine Grafikkarte.


    Ich habe meine Grafikkarte unter http://www.techpowerup.com/vga…19/asus-gt520-1024-111128 gefunden, nur leider ist die dort angegebene Version 70.08.5C.00.00 genau die selbe, die mir X ins Log schreibt. Eine neuere scheint's nicht zu geben.


    Hm, ich hab eine Asus GT520 (GF119) mit dem 340.96-Treiber und Kernel 4.2.0-35-generic in meinem Entwicklungsrechner am laufen:

    Code
    01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520] (rev a1) (prog-if 00 [VGA controller])
            Subsystem: ASUSTeK Computer Inc. Device 83a0


    Leider ist das nicht die selbe Karte wie die meine:

    Code
    01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 520] (rev a1) (prog-if 00 [VGA controller])
            Subsystem: ASUSTeK Computer Inc. Device 83d2


    GF119 vs. GF108 und die Device-ID ist auch unterschiedlich und für die 83a0 gibt's unter http://www.techpowerup.com/vga…08/asus-gt520-1024-110322 auch eine anderen VideoBIOS Version, also sind das wohl unterschiedliche Karten (ohne und mit "silent" im Namen, scheint sich mehr als der Lüfter zu unterscheiden).


    Es läuft also wohl wirklich darauf hinaus, dass ich die Grafikkarte austausche. Ein kurzer Test mit einer anderen (uralten) nvidia Karte (ohne HDMI und damit auch ohne Ton) zeigte mir auch durchaus ein Bild, mein System ist also nicht grundsätzlich unbrauchbar, nur die ASUS GT520 Silent scheint ein extrem ungünstiger Griff gewesen zu sein. Im Nvidia-Development-Forum finden sich auch andere Nutzer genau dieser Karte, die die gleichen Probleme meldeten und dann scheinbar irgendwann aufgegeben haben (jedenfalls war keine Erfolgs-Rückmeldung zu lesen). Da die Karte eine Kaufempfehlung hier im Forum war, bin ich erstaunt, dass es da nicht mehr Problemreports gibt, aber vielleicht haben viele eine andere Karte verwendet, die war schon damals schlecht zu bekommen.

    Also wir hätten da ein Kernel-Log: http://www.spinnaker.de/tmp/kern.log.
    Dann noch das Xorg.log: http://www.spinnaker.de/tmp/Xorg.1.log.
    In letzterem findet sich auch der Backtrace. Falls man da noch einen besseren erstellen kann, bitte ein kurzer Link zur Anleitung, wie das geht.
    Falls es was zur Sache tut hier noch die xorg.conf.yavdr, aber die ist bislang noch automatisch erstellter Default: http://www.spinnaker.de/tmp/xorg.conf.yavdr


    Dann haben wir noch

    Code
    # dkms status
    media-build-experimental, 0~20150719.122100, 3.13.0-85-generic, x86_64: installed
    nvidia-304, 304.131, 3.13.0-85-generic, x86_64: installed


    Und vielleicht interessiert noch

    Code
    # dpkg -l nvidia\* '*304*' | grep -v ^u
    ||/ Name                                  Version                                      Architektur  Beschreibung
    +++-===========================-=====================================-============-============================
    ii  libcuda1-304                304.131-0ubuntu0.14.04.1              amd64        NVIDIA CUDA runtime library
    ii  nvidia-304                  304.131-0ubuntu0.14.04.1              amd64        NVIDIA legacy binary driver - version 304.131
    ii  nvidia-common               1:0.2.91.11                           amd64        transitional package for ubuntu-drivers-common
    ii  nvidia-libopencl1-304       304.131-0ubuntu0.14.04.1              amd64        NVIDIA OpenCL Driver and ICD Loader library
    ii  nvidia-opencl-icd-304       304.131-0ubuntu0.14.04.1              amd64        NVIDIA OpenCL ICD
    ii  nvidia-settings             331.20-0ubuntu8                       amd64        Tool for configuring the NVIDIA graphics driver


    Was habe ich jetzt noch vergessen?

    Okay, jetzt habe ich nochmal alle 352-Pakete gepurged und die 304er installiert.
    Leider bleibt der Bildschirm immer noch schwarz, diesmal weil der X-Server mit einem Segfault abstürzt ;(


    Das ganze reproduzierbar.


    Welche Optionen habe ich jetzt noch? Andere Grafikkarte probieren (habe leider keine mit HDMI) oder beim guten alten yaVDR 0.5 bleiben.
    Oder hat jemand eine bessere Idee?


    Gruß
    Roland

    So grundsätzlich gilt Deine GT520 schon als alte Karte (Legacy), aber der 304er Strang ist kein alter Treiber. Im Gegenteil, Nvidia wirft immer wieder ältere GPUs aus dem aktuelle Strang und pflegt diese im Legacy Strang 304.


    Das war mir nicht bewusst, dann werde ich den 304er Treibern noch mal einen Chance geben und weiter testen.


    Nun müsste man klären warum der Schirm schwarz bleibt, unterstützt der 304er Deine GPU nicht oder ist es ein Konfigurationsproblem? Was sagt Xorg.0.log bzw. Xorg.1.log?


    Das muss ich mir nochmal genauer anschauen, ich hatte vermutlich noch ein wenig Mix zwischen 304 und 352. Wenn ich jetzt sicher bin, dass 304 das System der Wahl ist, werde ich sauberer prüfen, dass 352 auch wirklich runter vom System ist.


    Man fleddert keinen 2 Jahre alten Thread für ein aktuelles Problem, daher nach yaVDR verschoben.


    Danke dafür. Im alten Thread war die Hardware-Beschreibung halt identisch zu der meinen und das Problem war damals nicht gelöst worden, daher die Frage, ob es vielleicht doch noch eine Lösung gab, die hier nicht dokumentiert wurde.


    Tschoeeee
    Roland

    Gibt es hier inzwischen ein Update oder eine Lösung?


    Ich habe die gleiche Kombination (ASRock H61M/U3S3 mit ASUS ENGT520 SILENT) und mit yaVDR 0.5 (nvidia-304) läuft das problemlos.
    Nun versuche ich mich an yaVDR 0.6.1 (nvidia-352) und damit bekomme ich den gleichen Fehler:

    Code
    (EE) NVIDIA(GPU-0): Failed to initialize DMA.


    Die Meldung

    Code
    (II) NVIDIA: Using 3072.00 MB of virtual memory for indirect memory
    (II) NVIDIA:     access.

    hatte ich schon bei yaVDR 0.5, das scheint also kein Showstopper zu sein.


    Einen BIOS-Update auf 2.40 habe ich durchgeführt, das ändert nichts am Problem (hat mir nur CIR und WoL zerschossen, aber das habe ich zum Glück wieder hinbekommen)


    Das VideoBIOS ist 70.08.5c.00.00 und wohl die aktuellste Version, die es gibt.


    Ein Downgrade der nvidia-Treiber auf 304 innerhalb yaVDR 0.6.1 hat leider auch nicht den erhofften Erfolg gebracht (dann bleibt der Bildschirm schwarz), daran könnte ich nochmal weiter forschen, aber eigentlich will ich ja eine aktuelle yaVDR-Version verwenden und dann ist es kontraproduktiv, die nvidia-Treiber auf altes Niveau downzugraden (trotzdem würde ich auch diesen Weg gehen, aber nach bald 10 Stunden Gebastel bin ich jetzt eigentlich froh, dass mein yavdr 0.5 wieder läuft).


    Oder sollte ein Tausch der Grafikkarte wirklich die einzige Möglichkeit sein?


    Tschoeeee
    Roland

    Hi, das VompImage habe ich kopiert. Es scheint auch zu starten, der Balken wandert nach rechts bis zum Ende, dann wirds schwarz und nichts passiert mehr.
    Muss ich den Vompserver im Easyvdr noch konfigurieren? Muss mich den Vompclienten noch konfigurieren? Ich habe den Mpeg Schlüssel eingetragen mehr nicht.


    Zumindest beim yaVDR musste ich einen aktuelleren VOMPserver aus dem GIT auschecken und bauen, vorher war das Verhalten ähnlich zu dem von Dir beschriebenen.


    Tschoeeee
    Roland

    Nach der Neuinstallation mit Precise (x64) kann ich WOL nicht mehr im BIOS einschalten. Der VDR fährt dann nicht mehr herunter sondern startet gleich neu (reboot).

    Rebootet das System bei Dir sofort?
    Bei mir sieht das Verhalten so aus, dass der VDR scheinbar runter fährt, alle Lampen und Lüfter gehen aus, das Licht in der USB-Maus schaltet sich ab.
    Dann dauert es ca. 4 Sekunden und das System schaltet sich wieder ein, als hätte es von irgendwoher (WoL oder über CIR) einen Befehl dazu bekommen.


    Ein kurzer Versuch mit yaVDR 0.4.0 zeigte übrigens das gleiche Verhalten, obwohl das auf Natty (x64) basiert.


    Tschoeeee
    Roland

    schon mal versucht danach sofort erneut runterzufahren? Bei obigem Motherboard (siehe Post oben Asus P8H61-I ) bleibt die Kiste dann (bei mir zumindest) aus. Und laesst sich spaeter per WOL auch wieder ganz normal aufwecken.

    Ich habe, sobald der VDR wieder gestartet war, gleich wieder die PowerOff-Taste gedrückt und ihn wieder in den Schlaf geschickt, woraufhin sich das ganze wiederholte. Ich weiß auch nicht genau, wie ich das automatisieren sollte, wann darf er durchbooten und wann muss er sich selbst beim Booten das nächste "shutdown -h now" schicken?


    Als Workaround kann ich statt shutdown auf Suspend to RAM schalten, das ist zwar nicht wesentlich schneller als shutdown und boot, aber immerhin lässt sich die Kiste schlafen legen und WOL funktioniert damit auch.


    Tschoeeee
    Roland

    Wenn ich im BIOS unter ACPI "PCI Devices Power On" einschalte funktioniert WOL wunderbar,
    jedoch fährt das PC nicht mehr herunter sondern startet direkt neu...
    Schalte ich "PCI Devices Power On" aus, gibts auch kein WOL.... dafür schaltet sich der PC wieder ordnungsgemäß ab.

    Das kann ich leider nur bestätigen. Auch bei mir funktioniert WOL nicht, solange ich "PCI Devices Power On" abschalte.
    Schalte ich es ein, fährt der VDR zwar runter, alle Lampen gehen aus, aber ca. 5 Sekunden später schaltet er sich automatisch wieder ein.


    Ein Versuch mit yavdr 0.4.0 (statt 0.5.0alpha1) brachte diesbezüglich auch keine Verbesserung.
    Ebensowenig das im Ubuntu-Wiki als Workaround empfohlene "acpi=force" in den Kernel-Options.


    Jetzt fällt mir auch nichts mehr zu dem Thema ein.


    Tschoeeee
    Roland

    Zitat

    Original von amair
    Dank der Hilfe von Christian ist die Ursache nun gefunden: zum Einen ist es ein Fehler im reelchannelscan Plugin, da dies bei der Serviceabfrage einen falschen Returnwert liefert. Dadurch "denkt" EnigmaNG, dass epgsearch läuft (bzw. ruft den EPGsearch Service im reelchan auf) und dann kracht's.
    Nun holt sich EnigmaNG direkt das EPGsearch Plugin und ruft den Service dann dort auf.


    Das ist nun im CVS-Stand gefixt.


    Danke, läuft jetzt perfekt.


    Tschoeeee
    Roland

    Zitat

    Original von amair
    Das deutet auf ein Problem bei der Wiederholungssuche hin. Ihr könntet diese mal abschalten, dann dürfte das nicht mehr auftreten. Wieso aber das "delete" zum Absturz führt muß ich erst noch genauer untersuchen.


    Wow, perfekte Fehlerdiagnose :)
    Stelle ich die Anzahl der Wiederholungen auf 0, segfaulted er nicht mehr. Sobald ich auf 1 oder mehr stelle, fliegt er gleich wieder ab.


    Tschoeeee
    Roland

    Auch bei mir hat VDR einen Segmentation Fault geworfen, wenn ich bei aktiviertem EnigmaNG die Details zu einer Sendung ansehen wollte (mit text2skin gibt's keine Probleme).


    Ich habe jetzt einen neuen VDR 1.4.7 ohne jegliche Patches gebaut und mit meinen normalen Plugins ist der immer noch an der selben Stelle abgestürzt. Daraufhin habe ich der Reihe nach alle Plugins deaktiviert und damit festgestellt, dass das Problem in der Kombination von EnigmaNG und reelchannelscan-Plugin 0.4.1. Sobald letzteres nur geladen ist (muss nichtmal gestartet werden), fliegt VDR mit folgendem Backtrace ab:



    Tschoeeee
    Roland

    Zitat

    Original von wilderigel
    Ne, läuft dann leider nicht durch:

    Code
    epg.c:761: error: redefinition of `const cEvent*


    Kann es sein, dass Du Deinen ersten Patch-Versuch (mit dem alten Patch) nicht rückstandsfrei wieder rausgenommen hast, bevor Du meinen aktualisierte Fassung eingespielt hast?


    Bei mir compiliert das nämlich ohne Meckern durch, ich weiß nur nicht, ob der Patch die erwünschte Wirkung hat...


    Tschoeeee
    Roland