Probleme mit eHD in einem xen-domU-vdr

  • Hallo zusammen,


    passend zu den Olympischen Winterspielen habe ich mich entschlossen auf nen HD-VDR aufzurüsten. Nach umfangreicher Recherche im Forum habe ich mir eine Reel eHD zugelegt und versuche nun diese in meinem vdr - der als eigene domU (also virtuelle Maschine) innerhalb XEN konfiguriert ist - zum laufen zu bringen.


    Aus den verschiedensten Anleitungen habe ich mir die nötigen Informationen zusammen gepickt und denke, dass mein Vorgehen eigentlich passen sollte. Aktuell bin ich jetzt bei dem Punkt "gebaute eHD Treibermodule laden" angelangt. Dieser schlägt jedoch leider mit folgender Meldung fehl:



    Was bisher geklappt hat:
    - eHD Karte in meine vdr-domU durchreichen:


    - Revision 13931 der Reelbox Installpakete auschecken
    - Treibermodule bauen, nach Anpassung der hdshm.c gemäß Wiki, obwohl dies ja eigentlich aktuell nicht mehr nötig sein sollte. Ich vermute jedoch, dass mein an XEN angepasster Kernel 2.6.26-2-xen-686 die Änderungen für 2.6.27 ebenfalls benötigt. Ohne diese hat das Bauen jedenfalls nicht funktioniert.
    - TFTPD-Server einrichten


    Ich hoffe einer der Experten wie IG88, C-3PO, Stalker, frodo, real_schorsch,... erbarmt sich meiner und hilft mir den Fehler zu finden :-)


    Vielen Dank im Voraus
    Grüße livefields


    EDIT:


    Ach so, hier vielleicht noch die dmesg Ausgabe (ich habe vor dem modprobe hdshm noch ein modprobe tun gemacht):

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von livefields ()

  • Hast du die pciback.hide Kernel Option gesetzt?

    Backend (zurzeit nicht mehr in Betrieb): yaVDR diskless - Asus M4N78 PRO - Nvidia GeForce 8300 onboard - AMD Athlon II X2 240 - Ram 4GB - 2x Terratec Cinergy C PCI HD

    yaVDR 0.4 Zotac MAG HD-ND01 ATOM 330 ION Mini PC - TT S2-3600 - LG 32LH3000

    ***************************************************************************

    "Es gibt Tage an denen verliert man, und es gibt Tage an denen gewinnen die anderen."

  • sk8ter : Ja, klar. Hatte ja bisher schon nen domU-vdr laufen, da wurde ne FF-Karte und ne Budget durchgereicht. Diese zwei Karten hab ich jetzt raus und dafür die eHD rein und ne TT S2-3200 - gleiche Steckplätze, dadurch passt auch das pciback.hide in der Dom0 noch.


    Auszug aus lspci -v in der Dom0:

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von livefields ()

  • Dann weiss ich leider nicht weiter, weil keine Kenntnisse der eHD. Ausser vielleicht nochmals überprüfen ob wirklich alle PCI Adressen durchgereicht sind. Mann weiss ja nie. ;)

    Backend (zurzeit nicht mehr in Betrieb): yaVDR diskless - Asus M4N78 PRO - Nvidia GeForce 8300 onboard - AMD Athlon II X2 240 - Ram 4GB - 2x Terratec Cinergy C PCI HD

    yaVDR 0.4 Zotac MAG HD-ND01 ATOM 330 ION Mini PC - TT S2-3600 - LG 32LH3000

    ***************************************************************************

    "Es gibt Tage an denen verliert man, und es gibt Tage an denen gewinnen die anderen."

  • Hm, mir fällt gerade auf, wenn ich die Ausgabe von lscpi -v im Wiki nehme und mit meiner vergleiche, steht bei mir hinter den zwei "Memory"-Zeilen jeweils ein [disabled]?! Das ist bei der beispielhaften Ausgabe im vdr-wiki nicht so:


    Code
    1. lspci -v
    2. 01:08.0 Multimedia controller: Micronas USA, Inc. Device 8100
    3. Subsystem: Micronas USA, Inc. Device 8100
    4. Flags: bus master, medium devsel, latency 32, IRQ 5
    5. Memory at e7fff000 (32-bit, non-prefetchable) [size=4K]
    6. Memory at d8000000 (32-bit, non-prefetchable) [size=128M]
    7. Capabilities: [40] Power Management version 2


    Meinst Du, es könnte vielleicht damit was zu tun haben? In meiner Fehlermeldung steht ja auch was von Speicherzugriffsfehler... Muss man den Speicher in der Dom0 separat "reservieren"?

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

  • Ich habe in meiner menu.lst noch die Kerneloptionen "pci=noacpi noirqdebug" drinn, weiss aber nicht mehr warum. Ich haeb schon länger nichts mehr mit VDR auf XEN gemacht. Damals hatte ich zwei DVB-C Karten durchgereicht. Und irgend etwas war glaub mal mit reserved memory irgendwas, daran kannich mich aber auch nicht mehr errinnern.


    Hoffe das hilft Dir weiter.


    Gruss
    Sk8ter


    :Edit
    Die Memory Sache hatte mit DMA Puffer zu tun. Das ging aber um die DVB Karten. Vielleicht hilft es dir ja trotzdem weiter.

    Backend (zurzeit nicht mehr in Betrieb): yaVDR diskless - Asus M4N78 PRO - Nvidia GeForce 8300 onboard - AMD Athlon II X2 240 - Ram 4GB - 2x Terratec Cinergy C PCI HD

    yaVDR 0.4 Zotac MAG HD-ND01 ATOM 330 ION Mini PC - TT S2-3600 - LG 32LH3000

    ***************************************************************************

    "Es gibt Tage an denen verliert man, und es gibt Tage an denen gewinnen die anderen."

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von sk8ter ()

  • Habe eben diesen hochinteressanten Thread gefunden, den ich jetzt mal Stück für Stück durcharbeiten werde. Es scheint ein spezielles Problem der eHD unter XEN in einer DomU zu sein. Ich hoffe ich werde genau so erfolgreich sein wie jimmy.

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

  • Ich bin mittlerweile vom Ubuntu (nein danke, nie wieder!) auch auf Debian Lenny mit 2.6.26-2-xen-amd64 (allerdings älteres Xen 3.2-1) umgestiegen.


    Der wichtigste Post im genannten Thread ist mein letzter. Der io_remap_pfn_range Bug war einige Wochen/Monate später, als ich nochmal ein Update gemacht habe, nicht im SVN korrigiert worden und ich vermute, er ist es immer noch nicht.


    Falls es damit nicht funktionieren sollte, melde dich nochmal.

  • Hey jimmy, erst mal danke, dass Du Dich hier einklinkst ;)


    Hab nochmal den Sourcecode angeschaut, den io_remap_pfn_range hatte ich schon nach Deiner Anleitung angepasst. Leider hat dies nichts an meinem Fehler beim Laden des Moduls geändert :-(


    War es bei Dir eigentlich so, dass das Modul sich noch per modprobe laden lies und es erst einen Schritt später beim hdboot krachte? Ich bekomme die Fehler nämlich ja bereits nach dem modprobe-Aufruf. Hast Du noch nen anderen Tipp für mich?


    Welche Revision der Reelbox-Installs benutzt Du?

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

  • So, um die XEN-Problematik erst mal außen vor zu lassen, habe ich versucht, die eHD in der Dom0 (also im Prinzip einem Standard Lenny-System) zum spielen zu bekommen. Der TFTP-Server läuft und funktioniert. Als Treiber habe ich wieder Revision 13931 von Reelbox gezogen und folgende Änderungen (der XEN-Kernel 2.6.26-2-xen-amd64 erfordert auch schon die Änderungen die normalerweise erst ab 2.6.27 nötig sind) an der hdshm.c vorgenommen



    und anschließend übersetzt. modprobe tun und dann modprobe hdshm schlägt dies mit folgender Meldung in dmesg fehl:



    Auf der Console bekomme ich den Output:



    Hat mir jemand nen Tipp, wo hier das Problem liegen könnte? Wie gesagt, es laufen keine virtuellen XEN-Maschinen, die Karte soll testweise erst mal ganz normal unter dem Host-System betrieben werden.

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

  • Ich benutze die SVN Version 9302, versuche es mal damit. Ich habe hier auch noch Version 12352, aber irgendwie gab es damit Probleme, kann mich nicht mehr genau erinnern.
    Vieleicht wage ich irgendwann nochmal einen Updateversuch, aber momentan fehlt mir leider die Zeit zum Debuggen.

  • Ich geb's auf. Bekomme das Teil einfach nicht zum spielen. Wer die Karte haben will, PN an mich.

    im Aufbau: e-Tobi vdr
    Debian Linux 5.0 (Lenny) mit XEN 3.4.1
    vdr in eigener DomU - Kernel 2.6.26-2-xen-686
    TT Premium S2-6400
    AMD Athlon X2 5050e, GA-M720-US3, 4 GB RAM

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von livefields ()

  • Ich hatte bei mir ähnliche Probleme die aber vom BIOS des Mainboardes herrührten (ASUS M3A-HDMI). Die eHD funktionierte bei mir nur mit einem alten BIOS erst ab den 1200er Versioenen gingen auch die neuen.


    Die eHD kommuniziert mit ihrem Linux direkt mit dem vom hdshm Module reservierten Speicher und hier scheint dein Problem zu liegen Xen lässt den Zugriff wohl nicht zu bzw kommt mit der Art und weise wie dies umgesetzt wurde nicht zurecht.


    Unter OpenSuse oder Ubuntu hatte ich aber bisher fast keine Probleme die eHD zum Laufen zu bewegen, Debian habe ich nicht probiert. Ich habe aber auch nicht herum experimentiert mit Xen oder 64 Bit.


    Bei OpenSuse musste ich zwingend den Default Kernel verwenden, sonst gab es auch hier Probleme beim Speicherzugriff.

    Gruß
    Frodo