iMon LCD (ffdc) hängt sich mit bestimmter CPU auf!

  • Mein iMon LCD (ffdc) hängt sich mit bestimmter CPU auf!


    Für ein wenig mehr an Performance wollte ich die CPU in meinem System auf Athlon II X2 260 (2x3,2 GHz) aufrüsten. Leider hat sich herausgestellt, dass das iMon damit nicht funktioniert. Meistens hängt sich die Anzeige schon kurz nach dem Start auf, so dass sich im Display nichts mehr bewegt.


    Wenn dann z.b. das Display via SVDRPSEND abgeschaltet werden soll, dann kommt ein Segfault. Das kann auch Stunden nach dem "Einfrieren" sein. Oder erst beim herunter fahren. Bei einem VDR Neustart sind die DVB-Adapter nicht mehr zu öffnen und man muss einen reboot machen.


    Baue ich den Athlon 4850e (2x2,5 GHz) wieder ein läuft es 8|


    Es gib ein Ticket: http://j.mp/1tKARKz
    Und einen Beitrag im HTPC-Forum: http://j.mp/1tKAWOj

  • Habe nun einen Athlon II X2 240e (2x2,8GHz) getestet. Auch da hängt sich das Display auf; aber weniger oft.


    Es kann doch nicht sein, dass die CPU zu schnell ist? bei 2x2,5GHz alles Ok, bei 2x2,8GHz gelegentliche Aufhänger und bei 2x3,2GHz ständige Aufhänger...


    Müsste entweder am Plugin oder am Treiber liegen...


    Habe den media_build experimental drauf und Gen2VDR V5 64-Bit


    Eventuel ein 64-Bit Problem?

  • Ich lasse gerade Memtest86 laufen - Ist ja bei Gen2VDR schön im Bootmenü auswählbar ;)


    Edit: Aber läuft der RAM nicht immer gleich schnell? (Bei mir 400 MHz [DDR2-800])

  • So der Speicher ist es wohl nicht "Pass complete, no errors"


    Es betrifft ja auch auch nur das imon-Plugin... Bei einem Speicherfehler müssten ja unterschiedliche Effekte auftreten..

  • Hab die CPU mit cpufreq-set auf max. 2.1GHz begrenzt. Das Display hat sich eben trotzdem aufgehängt. Im Log nichts zu sehen. Alles funktioniert normal, außer dass das Display eingefroren ist.


    Wenn ich jetzt mit svdrpsend das Display abschalten würde, käme der Segfault und die Treiber wären vermutlich weg; inkl. der dvb-karten.


    ich versuche mal den letzten media_build-treiber drauf zu machen...

  • Aktuelle media-build-experimental bringt keine Besserung. Das Display ist auch gestern Abend wieder eingefroren.


    So weit ich das beurteilen kann, passiert das immer, wenn Text gescrollt wird...


    Nach dem Einfrieren konnte ich noch stundenlang den VDR normal verwenden (Aufnahmen anschauen, Timer editieren, usw...). Erst beim beenden kommen die Fehlermeldungen im Log und das Display geht nicht aus...

  • Gestern wieder kurz nach dem eine Meldung gescrollt wurde einfach stehen geblieben...


    Im Log nichts. Wo kann ich da ansetzen. Kann man im Plugin da irgendwo ein paar Debug-Ausgaben oder ein sleep einbauen?


    Die Entwicklung scheit ja schon seit Jahren eingestellt zu sein ;(

  • Ich würde bei solchen "Erscheinungen" eher auf ein Interrupt Problem tippen. Der einzige AMD-VDR den ich in meinen Fingern hatte, machte ähnlichen Stress. Erst das "Festdengeln" der CPUfreq und das Durchprobieren der USB-Anschlüsse brachte das Teil inkl. iMON-Display zum Laufen. Seitdem verwende ich nur noch Intel-Plattformen.

  • helau
    Das probiere ich auf jeden Fall mal durch


    iNOB
    Aber mit der 4850e-CPU geht das 100% problemlos seit Jahren...
    Die Interupts sind so aufgeteilt:


    USB-Port mal umgesteckt... dmesg:

    Code
    [	3.976147] input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci0000:00/0000:00:02.0/usb3/3-4/3-4:1.0/input/input9
    [	3.997765] imon 3-4:1.0: 0xffdc iMON LCD, MCE IR
    [	3.997768]  (id 0x9f)
    [	3.997770] imon 3-4:1.0: imon_set_display_type: overriding display type to 2 via modparam
  • Das Umstecken auf die anderen internen USB hat leider nichts gebracht.


    Wie aktiviere ich den Debug unter Gen2VDR V5?

    Was wird dann ausgegeben? Würde das was bringen?

  • Aber der Segfault passiert immer erst beim Runter fahren, oder beim Wechsel zu XBMC...


    Das Display hängt sich auf... Man kann alles noch über Stunden weiter verwenden. Erst beim Beenden (Das Display soll abgeschaltet werden) oder beim Wechsel zu XBMC (Display wird hier auch abgeschaltet) kommt der Crash!


    Zu dem Zeitpunkt, wo sich das Display aufhängt ist nichts im Log zu finden.

  • Hast Du denn mal einen BT erstellt? Eventuell lässt sich damit erkennen, wo es klemmt.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Wie? Reicht das eventuel:


    Aber passiert wie gesagt erst Stunden nach dem Aufhängen!

  • Naja, mir sagt das nichts, aber vielleicht einem Programmierer des Plugins. :D Sieht irgendwie nach Problemen in der USB-Kommunikation aus.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hallo MegaV0lt,


    ich denke, das Problem sind die CPUs, die nicht 100%ig mit dem Mainboard kompatibel sind. Es sind AM3 CPUs, die erst ab Biosversion 0802 unterstützt werden und bei dir Probleme machen. AM3 Prozessoren laufen zwar in AM2+ Mainboards, jedoch gibt es gewisse Einschränkungen zu echten AM3-Mainboards (musst du googlen was genau, aber ich glaube bestimmte Stromsparmechanismen gehören dazu).
    Am RAM liegt es, wie schon geschrieben nicht, da CPU-Takt und RAM-Geschwindigkeit asynchron arbeiten. Dadurch hat der RAM immer den richtigen Arbeitstakt.


    Was für einen Kernel benutzt du, Genkernel oder einen selbstkompilierten? Bei einem selbstkompilierten ist es vielleicht einfacher die entsprechenden Optionen für einen Test(kernel) auszuschalten, die vielleicht helfen können, den Fehler zu lokalisieren. Bei einem Genkernel könnte man die entsprechenden Module blacklisten.


    Falls es an den CPUs und bestimmten Stromsparmechanismen, die problematisch sind liegen sollte, könnte z.B. die Deaktivierung der C-States helfen oder du schaltest den Powernowd (oder welchen Power-Govenor du benützt) vorübergehend testweise aus.
    Ich erinnere mich, dass es bei C-States und USB in der Vergangenheit öfters Probleme gab und falls die AM3-CPU Funktionen nicht 100%ig vom Chipsatz unterstützt werden oder der Kernel eine Funktion freischaltet, die eigentlich vom Bios aus Kompatibilitätsgründen gesperrt ist, kann es Probleme geben.


    Lädt dein Kernel beim Start CPU-Microcode zur Fehlerbehebung der CPU? Falls nein, könnte das vielleicht helfen.


    Soweit mal meine Gedanken für den Moment.


    Grüße,


    Johannes

    VDR: Silverstone LC16M, 2x DVBSky S952, Asrock B85 Pro4, Core i3-4170, 8GB Ram, 525GB SSD + 4TB HD, DVD, System: gentoo amd64, Softhddevice

  • Danke für die neuen Ansätze!


    Das BIOS ist 0901 und Auf der Webseite werden die CPU als unterstützt angegeben
    dmesg


    Der Kernel ist

    Code
    Linux hdvdr01 3.15.10-gentoo #1 SMP PREEMPT Mon Aug 18 15:30:21 CEST 2014 x86_64 AMD Athlon(tm) II X2 240e Processor AuthenticAMD GNU/Linux


    .config


    Das mit den Microcodes hört sich interessand an. Wie kann ich das prüfen, ob da was geladen wird, oder ob es solche Codes gibt?
    C1E ist im BIOS schon immer aus (LIRC)
    CPUFreqUtils habe ich mal deaktiviert... Hat nichts gebracht. Hat sich eben schon aufgehängt ;(

  • Dass deine CPUs vom Bios unterstützt werden, hab ich gesehen, aber wie gesagt, ob sie wirklich 100%ig damit laufen oder nur unter Windows ist eine andere Geschichte.


    Bei dir wird kein Microcode geladen, das würdest du im dmesg sehen, bei mir am Desktop-PC sieht es z.B. so aus:


    [ 2.666478] microcode: CPU0: patch_level=0x06000822
    [ 2.674791] microcode: CPU1: patch_level=0x06000822
    [ 2.674805] microcode: CPU2: patch_level=0x06000822
    [ 2.674815] microcode: CPU3: patch_level=0x06000822
    [ 2.674822] microcode: CPU4: patch_level=0x06000822
    [ 2.674830] microcode: CPU5: patch_level=0x06000822
    [ 2.674848] microcode: CPU6: patch_level=0x06000822
    [ 2.674859] microcode: CPU7: patch_level=0x06000822
    [ 2.674925] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba


    Wie du es aktivierst steht hier:


    http://wiki.gentoo.org/wiki/AMD_microcode


    Es gibt aber nicht für alle CPUs Patches, musst du probieren, ob beim Start was geladen wird. Ich glaube, bei AMD ist es noch nicht so lange Usus wie bei Intel.


    Ich hab mal deine dmesg durchgesehen und nicht viel außergewöhnliches gesehen, bis auf ein paar experimentelle Treiber (Mediastack) und vielleicht unnötige Dinge, die geladen werden, wie Druckerunterstützung und KVM. Serial brauchst du ja scheinbar für lirc.
    Das hier:
    [ 3.993290] ACPI Warning: SystemIO range 0x0000000000000700-0x000000000000073f conflicts with OpRegion 0x0000000000000700-0x000000000000073f (\SM00) (20140214/utaddress-258)
    [ 3.993295] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver


    ist mir auch noch aufgefallen und ich habe hier https://debianforum.de/forum/viewtopic.php?f=33&t=119197 etwas dazu gefunden. Wer weiß, vielleicht ändert es ja was. :)

    VDR: Silverstone LC16M, 2x DVBSky S952, Asrock B85 Pro4, Core i3-4170, 8GB Ram, 525GB SSD + 4TB HD, DVD, System: gentoo amd64, Softhddevice

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!