HDe Treiberproblem in 32 Bit Xen DomU mit 64Bit Dom0

    Hallo zusammen,


    ich habe hier eine Xen 32 Bit DomU aufgesetzt und hatte gehofft, damit alle 64 Bit Probleme der HDe Treiber zu umgehen...


    Folgendes passiert jedoch, wenn ich nach der OpenSuse VDR DVB-S2 Anleitung (inkl. 64 Bit Patches) Anleitung vorgehe:


    #./hdboot
    Decypher PCI BAR1: ffffffff
    Failed to mmap PCI (Invalid argument)
    Segmentation fault


    /var/log/messages:
    hdshm_init_struct: Phys start 00000000cb000000, start ffffc20000100000, nc-start ffffc20000480000
    hde_fb: init 0
    ioctl32(hdboot:3745): Unknown cmd fd(3) cmd(8004640a){t:'d';sz:4} arg(00000000) on /dev/hdshm
    hdboot[3745]: segfault at 8010c rip 8048a8c rsp ffafd8b0 error 4



    Konfiguration


    Dom0
    Ubuntu Hardy, Xen 3.2, kernel: 2.6.24-16.30zng1_amd64 (mit Xen network fix)


    DomU
    Ubuntu Hardy, arch=i386 (uname -m liefert jedoch x86_64)
    Der HDe Treiber ließ sich auch nur mit den Header Files des 64 Bit Dom0 Kernels compilieren.
    extra = 'swiotlb=force noirqdebug iommu=soft'


    Die HDe wurde mit den entsprechenden Parametern an die VDR DomU durchgereicht und ist sichtbar:


    # lspci -v
    00:00.0 Multimedia controller: Micronas USA, Inc. Unknown device 8100
    Subsystem: Micronas USA, Inc. Unknown device 8100
    Flags: medium devsel, IRQ 21
    Memory at d7fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
    Memory at c8000000 (32-bit, non-prefetchable) [disabled] [size=128M]
    Capabilities: [40] Power Management version 2



    Was ich schon probiert habe:
    - Reelbox SVN Treiber von heute
    - Reelbox SVN Trieber rev.5848
    (jeweils hdboot, linux.bin, shmnetd & hdshm.ko komplett ausgetauscht)



    Hat jemand noch eine Idee ?

    Das war einer meiner ersten Xen Versuche und mir war vorher so nicht klar, dass er zwar alle i386 Pakete in der DomU installiert, aber man mit Kerneltreibern anscheinend doch an die 64 Bit der Dom0 gebunden ist.


    Ich würde die VDR DomU notfalls auch komplett neu mit 64 Bit aufsetzen, wenn das der richtige Weg ist und es hoffentlich nicht später nicht mit einigen Userspace Programmen 64 Bit Probleme gibt.
    Ich habe allerdings in einem anderen Thread gelesen, dass die uint32 HDe Pachtches das Problem eventuell nicht beheben und es nur später knallt. Wie stabil ist er wirklich in einen reinen 64 Bit System ?


    Mir ist aber gerade noch ein möglicher Fehler aufgefallen: Da ich alles auf 32 Bit haben wollte, habe ich den HDe Kerneltreiber innerhalb der DomU kompiliert, was evtl. Blödsinn ist. Ich werde das nochmal in der Dom0 versuchen und ihn dann in die DomU kopieren.

    Zitat

    Originally posted by jimmy
    Das war einer meiner ersten Xen Versuche und mir war vorher so nicht klar, dass er zwar alle i386 Pakete in der DomU installiert, aber man mit Kerneltreibern anscheinend doch an die 64 Bit der Dom0 gebunden ist.


    Ich würde die VDR DomU notfalls auch komplett neu mit 64 Bit aufsetzen, wenn das der richtige Weg ist und es hoffentlich nicht später nicht mit einigen Userspace Programmen 64 Bit Probleme gibt.
    Ich habe allerdings in einem anderen Thread gelesen, dass die uint32 HDe Pachtches das Problem eventuell nicht beheben und es nur später knallt. Wie stabil ist er wirklich in einen reinen 64 Bit System ?


    Mir ist aber gerade noch ein möglicher Fehler aufgefallen: Da ich alles auf 32 Bit haben wollte, habe ich den HDe Kerneltreiber innerhalb der DomU kompiliert, was evtl. Blödsinn ist. Ich werde das nochmal in der Dom0 versuchen und ihn dann in die DomU kopieren.


    Hi,


    also ich habe ein echtes x86_64 openSUSE System und darin eine eHD. Ich konnte bisher keine Probleme feststellen die nicht auch bei x86 auftreten. Vielleicht kann real_schorsch noch was dazu sagen? Vielleicht gibts den Treiber auch bald für beide Systeme?


    Wie gesagt die Karte läuft in meinem Live VDR...

    Ich habe die DomU jetzt nochmal neu in 64bit aufgesetzt und habe jedoch immernoch das gleiche Problem:


    #./hdboot
    Decypher PCI BAR1: c8000000
    Failed to mmap PCI (Bad address)


    Ich habe den Treiber jeweils in der Dom0 und DomU compiliert und in der DomU geladen - kein Unterschied.


    Wenn ich den Treiber direkt in der Dom0 lade und hdboot dort starte, funktioniert es!:


    # ./hdboot
    Decypher PCI BAR1: c8000000
    Warm Reset
    Timeout: U-Boot not ready for PCI boot


    Wo ist das Problem?


    Fehlt noch eine Resource?


    DomU:
    # lspci -v
    00:00.0 Multimedia controller: Micronas USA, Inc. Unknown device 8100
    Subsystem: Micronas USA, Inc. Unknown device 8100
    Flags: medium devsel, IRQ 21
    Memory at d7fff000 (32-bit, non-prefetchable) [disabled] [size=4K]
    Memory at c8000000 (32-bit, non-prefetchable) [disabled] [size=128M]
    Capabilities: [40] Power Management version 2


    DomU /var/log/messages:
    hdshm_init_struct: Phys start 00000000cb000000, start ffffc20000080000, nc-start ffffc20000400000
    hde_fb: init 0
    hdboot[3703]: segfault at 8010c rip 400dd4 rsp 7fff500c15c0 error 4
    hde_fb: exit


    Edit: Tippfehler korrigiert, in der Dom0 funktioniert der Treiber

    Mit Xen und der HDe wirst Du wahrscheinlich nicht glücklcih werden.


    Das errinnert mich an jemand der mit Taucherflossen eine Berg besteigen will ...


    Beim Zusammenspiel zwischen dem Host-System und der HDe kommunizieren Prozesse direkt über shared memory. IMHO macht das Xen so nicht mit.

    Das Shared Memory liegt aber nur auf der HDE, das müsste sogar gehen. Es könnte aber sein, dass das mmap eines PCI-Bereichs unter XEN im Userspace nicht funktioniert, habe ich noch nicht probiert. hdboot geht da nicht über den Treiber sondern mapped das selber.

    Ich glaube nicht, daß Xen für Deine Anforderungen wirklich das Richtige ist.
    PCI-Passthrough ist noch recht experimentell und Hauptsächlich mit Netzwerkkarten und RAID-Controllern getestet... weniger mit Grafikkarten oder gar TV-Tunern oder "special purpose" Karten!


    "Nur" um 32/64bit Probleme zu lösenist Xen per-se der falsche Ansatz. Wie wäre es denn mit einem 64bit Kernel und 32bit Userland? Das funktioniert auch ohne jegliche Virtualisierung wunderbar.
    Oder noch einfacher: wenn es Probleme mit 64bit gibt, warum nicht gleich bei 32bit bleiben?


    Gruß,
    Razor

    Zitat

    Original von baltasar
    Beim Zusammenspiel zwischen dem Host-System und der HDe kommunizieren Prozesse direkt über shared memory. IMHO macht das Xen so nicht mit.


    Zitat

    Original von Razorblade
    Ich glaube nicht, daß Xen für Deine Anforderungen wirklich das Richtige ist.
    PCI-Passthrough ist noch recht experimentell und Hauptsächlich mit Netzwerkkarten und RAID-Controllern getestet... weniger mit Grafikkarten oder gar TV-Tunern oder "special purpose" Karten!

    Ich glaube, ihr unterschätzt Xen. Soweit ich mitbekommen habe, haben hier einige VDRs mit DVB Karten unter Xen erfolgreich am laufen.
    Und ich selbst habe eine andere DomU mit acht Framegrabbern ( bt878 ) stabil am laufen und ich glaube mich zu erinnern, dass da auch einiges über shared memory läuft.


    Zitat

    "Nur" um 32/64bit Probleme zu lösenist Xen per-se der falsche Ansatz.

    Ich habe Xen aufgesetzt, weil ich die Virtualisierung brauche, nicht wegen 32/64 Bit Problemen, das wäre ja Irrsinn.


    Zitat

    Wie wäre es denn mit einem 64bit Kernel und 32bit Userland? Das funktioniert auch ohne jegliche Virtualisierung wunderbar.

    64bit Kernel und 32bit Userland: siehe erster Beitrag. Allerdings brauche ich die Virtualisierung.


    Zitat

    Oder noch einfacher: wenn es Probleme mit 64bit gibt, warum nicht gleich bei 32bit bleiben?

    U.a. weil ich 8GB RAM im Server habe, die ich auch brauche. Aber mal abgesehen davon, wird mittelfristig kein Weg an 64Bit vorbeiführen, wenn man eine aktuelle Rechnerhardware aufsetzt.


    Ich wäre, nach wie vor, über eine Idee zur Lösung des Problems sehr dankbar, da eine HDe Treiber + VDR Installation in der Dom0 eigentlich aus diversen Gründen für mich nicht in Frage kommt.

    Ok entschuldige, ich dachte Du wolltest mit Xen wirklich nur die 32/64bit Problematik angehen, ok dann gehe ich mal etwas ins Detail:


    Wenn Du die HDe per PCI-Passthrough an die DomU weitergibst, mußt Du natürlich auch das Kernelmodul gegen den DomU (also dann 32bit) Kernel kompilieren.


    Setzt Du selbstkompilierte Kernel ein oder von der Distribution? Welche Disti überhaupt?


    Ich habe gute Erfahrung mit den Dom0 Kerneln von Gentoo (derzeit ein 2.6.21) oder Ubuntu (sogar 2.6.24.3) und "Vanilla"-Kernel (ab 2.6.24) als DomU (allerdings noch nicht mit PCI Passthrough getestet).


    Hast Du denn in der Dom0 das PCI Device auch sauber versteckt?
    "pciback 0000:01:00.0: seizing device" im dmesg zu sehen?



    Und ansonsten zum Thema 8GB RAM:
    Linux unterstützt bis zu 64GB RAM im 32bit mode (mit HIGHMEM64G und PAE) dann werden für Speicher und IO allerdings wieder 64bit Adressen benutzt, was die gleichen 64bit Probleme nach sich ziehen könnte, wie der "echte" 64bit Modus.
    Außerdem kann man auch ein 64bit Xen (also den Hypervisor) mit einer 32bit Dom0 laufen lassen. Die 8GB braucht man ja mit Xen üblicherweise nicht in der Dom0, sondern verteilt sie auf die DomU's.
    D.h. selbst ohne HIGHMEM64G könntest Du ein 64bit Xen, 32bit Dom0 und 32 oder 64bit DomU's laufen lassen -> Keine 64bit Treiberprobleme und trotzdem den ganzen Speicher auf die Dom's verteilen können.




    Gruß,
    Razor

    Zitat

    Original von Razorblade
    Wenn Du die HDe per PCI-Passthrough an die DomU weitergibst, mußt Du natürlich auch das Kernelmodul gegen den DomU (also dann 32bit) Kernel kompilieren.

    Siehe ersten Beitrag. Das geht IMHO so nicht:
    Ich habe keine HVM DomU aufgesetzt, d.h. es läuft kein vollständiger getrennter 32-Bit Kernel in der DomU, sondern es wird der 64-Bit Kernel der Dom0 genutzt,was zwingend 64-Bit Module erfordert, die in der Dom0 compiliert werden. Zu diesem Schluß bin ich jedenfalls gekommen. Eine HVM DomU kam für mich aufgrund des Overheads und da dort, soweit ich weiß, das Durchreichen der PCI Devices noch problematischer ist, nicht in Betracht.



    Zitat

    Original von Razorblade
    Setzt Du selbstkompilierte Kernel ein oder von der Distribution? Welche Disti überhaupt?

    Bitte ersten Beitrag lesen, mittlerweile habe ich auf 2.6.24-19-xen geupdatet.



    Zitat

    Original von Razorblade
    Hast Du denn in der Dom0 das PCI Device auch sauber versteckt?
    "pciback 0000:01:00.0: seizing device" im dmesg zu sehen?

    Ja, die wurden sauber versteckt. Aber vielen Dank nochmal für den Hinweis:
    Ich habe mittelerweile versucht die HDe in der Dom0 zum Laufen zu bekommen (siehe unten) und das "Verstecken" war der Grund für die Timeout: U-Boot not ready for PCI boot Meldung.



    Zitat

    Original von Razorblade
    Und ansonsten zum Thema 8GB RAM:
    Linux unterstützt bis zu 64GB RAM im 32bit mode (mit HIGHMEM64G und PAE) dann werden für Speicher und IO allerdings wieder 64bit Adressen benutzt, was die gleichen 64bit Probleme nach sich ziehen könnte, wie der "echte" 64bit Modus.

    Das hatte für mich so einen LIM/EMS Beigeschmack, deshalb habe ich es sein lassen. Richtig oder garnicht ;)



    Zitat

    Original von RazorbladeAußerdem kann man auch ein 64bit Xen (also den Hypervisor) mit einer 32bit Dom0 laufen lassen. Die 8GB braucht man ja mit Xen üblicherweise nicht in der Dom0, sondern verteilt sie auf die DomU's.
    D.h. selbst ohne HIGHMEM64G könntest Du ein 64bit Xen, 32bit Dom0 und 32 oder 64bit DomU's laufen lassen -> Keine 64bit Treiberprobleme und trotzdem den ganzen Speicher auf die Dom's verteilen können.

    Von der Variante 64bit Xen, 32bit Dom0, 32/64bit DomU hatte ich noch nichts gehört.


    Zusammengefasst kann ich mittlerweile sagen: 64-Bit ist NICHT das Problem. Xen ist das Problem.
    In der 64-Bit Dom0 funktioniert das Laden der Firmware und das Reel Logo ist zu sehen :-), jedoch verursacht shmnetd einen bösen Kernelfehler (Dump jetzt leider nicht griffbereit).
    Dieser hat mich zu folgenden Bug geführt:
    https://bugs.launchpad.net/xorg-server/+bug/68440 Seit zwei Jahren nicht gefix.....
    Aber ich bin von Ubuntu mittlerweile nichts anderes gewohnt, was die sich trauen zu releasen, ist echt das letzte.


    Unter einem 64 Bit Vanilla 2.6.24-19 Kernel ohne Xen scheint der Treiber und shmnetd problemlos zu laufen. Was natürlich keine Lösung für mein Problem ist, da ich Xen oder einen Ersatz brauche.


    Wenn ich das richtig rausgelesen habe, wäre KVM keine wirkliche Alternative , weil das "Durchreichen" von PCI Devices sehr eingeschränkt ist. Kann das jemand bestätigen?


    Ich werde den shmnetd/Dom0 Kerneldump noch nachliefern, vielleicht hilft das noch weiter.

    Zitat

    Siehe ersten Beitrag. Das geht IMHO so nicht: Ich habe keine HVM DomU aufgesetzt, d.h. es läuft kein vollständiger getrennter 32-Bit Kernel in der DomU, sondern es wird der 64-Bit Kernel der Dom0 genutzt,was zwingend 64-Bit Module erfordert, die in der Dom0 compiliert werden. Zu diesem Schluß bin ich jedenfalls gekommen. Eine HVM DomU kam für mich aufgrund des Overheads und da dort, soweit ich weiß, das Durchreichen der PCI Devices noch problematischer ist, nicht in Betracht.


    Da ist schlichtweg falsch. Auch bei PV läuft ein eigenständiger Kernel! Egal ob 32bit/64bit. Natürlich *kann* man auch den gleichen Kernel wie für die Dom0 benutzen (vorausgesetzt dieser hat auch die Frontend-Komponenten), man muß aber nicht. Meiner Meinung nach ist dies auch nicht zu empfehlen, da der Dom0 Kernel (eben wegen der Xen-Kompatibilität) stark gepatcht ist und nicht in aktuellen Versionen zur Verfügung steht.
    Meine Empfehlung wäre in der DomU (geändert) mal einen aktuellen 32bit Kernel laufen zu lassen (egal ob Vanilla oder von einer Disitri) und dagegen die HDe-Module zu kompilieren (innerhalb der laufenden DomU)...


    Gruß,
    Razor

    Zitat

    Original von ALT255
    Verstehe ich das richtig, dass der Bug nur unter Ubuntu bekannt ist.
    Dann Wechsel doch mal die Distri. Fedora oder Suse haben eine sehr gute Xen integration.

    Ja, es war definitiv ein Fehler Ubuntu zu nehmen. So schnell will ich aber nicht aufgeben....zur Not muss ich dann doch noch umsteigen :(


    Zitat

    Original von Razorblade
    Da ist schlichtweg falsch. Auch bei PV läuft ein eigenständiger Kernel! Egal ob 32bit/64bit. Natürlich *kann* man auch den gleichen Kernel wie für die Dom0 benutzen (vorausgesetzt dieser hat auch die Frontend-Komponenten), man muß aber nicht. Meiner Meinung nach ist dies auch nicht zu empfehlen, da der Dom0 Kernel (eben wegen der Xen-Kompatibilität) stark gepatcht ist und nicht in aktuellen Versionen zur Verfügung steht.

    Aha, ich lerne gerne dazu. Ich beschäftige mich schon zig Jahre mit Linux, mit Xen & 64Bit allerdings erst seit kurzem. Dann muß ich da noch etwas lesen.


    Zitat

    Original von Razorblade
    Meine Empfehlung wäre in der Dom0 mal einen aktuellen 32bit DomU-Kernel laufen zu lassen (egal ob Vanilla oder von einer Disitri) und dagegen die HDe-Module zu kompilieren (innerhalb der laufenden DomU)...

    DomU Kernel in der Dom0? Du meintest hier auch DomU, oder? Ich werde jetzt auf jeden Fall mal einen nicht-Xen Kernel in der DomU testen.



    Hier ist der Kernel Output, der erzeugt wird, wenn man shmnetd in der Dom0 mit 64Bit 2.6.24-19-xen Kernel startet. Das Laden der Firmware war zuvor fehlerfrei (Logo zu sehen):

    Code
    [644739.212697] hdshm_init_struct: Phys start 00000000cb000000, start ffffc20000200000, nc-start ffffc20000580000
[644739.484535] hde_fb: init 0
    Code
    hdboot -i linux.bin
Decypher PCI BAR1: c8000000
Uploading linux.bin, Length 5456970, virtual 0x7f33b6f41000, MIPS 0x2001000
Detected kernel entry 802ad000
memcpy done
Start CPU#0 at 802ad000

    Welche Eigenheit von shmnetd bzw. des HDe Treibers könnte diesen Fehler verursacht haben? Viele andere hardwarenahe Treiber laufen ja ohne Probleme.

    Ja ich meinte natürlich DomU, habe es im Beitrag geändert.


    Ich hätte da zwei Theorien:
    1. Die bisher verwendeten DomU Kernel waren entweder zu alt oder es gab 64bit Probleme.
    2. Der shm Treiber mag kein PCI-Passthrough, bzw die benutzen Speicherbereiche werden vom Hypervisor nicht sauber gemapped.


    Habe es gestern übrigens nochmal probiert einen aktuellen pvOps Kernel (also Vanilla mit Xen-Guest Support) zum Laufen zu bringen, klappt: 2.6.25.9.
    Allerdings gibt es woh immernoch kein PCI-Frontend, d.h. Passthrough wird nicht gehen.
    Nimm Dir doch mal die neuesten Ubuntu-Xen-Kernel-Sources und kompilier den als DomU/32bit.



    Gruß,
    Razor

    Bin hier am verzweifeln:


    - Ich habe die DomU neu aufgesetzt, 32 Bit Userland + 32 Bit 2.6.24-19-xen Kernel, wieder der gleiche Segmentation Fault beim hdshm laden in der DomU. (Bei nicht-xen Kerneln gab es einen Loader Error)
    - Ich habe die Dom0 komplett neu in 32 Bit, Kernel 2.6.24-19-xen mit PAE aufgesetzt, wieder praktisch der gleiche Kernelfehler beim shmnetd starten in der Dom0:

    Ist das wirklich ein Xen Problem oder kann es nicht doch sein, dass im hdshm noch ein Bug steckt, der nur unter Xen aufschlägt?

    Möglich ist da alles. Der hdshm-Treiber sieht zwar recht harmlos aus, macht aber etwas, was sonst nur wenige Treiber machen: Er "mappt" Speicher aus dem PCI-Bereich beim mmap-Aufruf im Kernel in den User-Space. Das ist der remap_pfn_range()-Call, bei dem es ihn dann zerlegt.


    Stellt sich die Frage, warum. Ich habe leider gerade kein 64Bit-System, hatte es aber mal damit probiert (Suse-irgendwas), und da hat es funktioniert. Heisst aber nichts, das MMU-Zeug ist manchmal fehlertolerant mit Zeitbombe...


    Man könnte mal das dbg1() im hdshm_mmap vor dem remap_pfn_range in printk umbauen, damit man sieht, was er eigentlich mappen will. Evtl. ist da schon das Problem.

    Wenn du mir einen Patch zukommen lässt, der die entsprechenden Debugausgaben generiert, teste ich gerne.
    Meine letzten Versuche habe ich mit der aktuellen SVN Version gemacht.

    Dass es so einfach ist, hatte ich nicht gedacht :) Bei mir war es zwar nicht Zeile 623, aber ich denke, ich habe die richtigen Ausgaben gefunden.


    Das kam beim Test in der 32Bit(PAE) Dom0 raus:

    Code
    [51444.109058] hdshm_init_struct: Phys start cb000000, start e0d00000, nc-start e1080000
[51444.415875] hde_fb: init 0
[52352.527577] mmap bse=e1080420 user b7ef6000 phys=1002000 size 1000 offset 0
uncached 1 pgprot 3f
MAP PHYSICAL: cb002000, length 1000

    Danach natürlich wieder sofort der Kernel Fehler:

    Der Test in der Dom0 ist immer etwas kritisch, weil er nach dem Kernel Fehler nicht mehr sauber runter fährt. Der Segmentation Fault beim hdshm Laden in dem DomU ist da nicht so problematisch.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden