Beiträge von Bench

    Hallo zusammen,
    ich habe die angeblich letzte DVBSky S952 DVB-S2 Twin Karte in einem Onlineshop gekauft, nachdem ich eine Rezension beim großen Fluß gelesen hab, dass die Karte auch in einer virtuellen Maschine unter Xen läuft... Jetzt beiße ich mir schon seit mehreren Tagen die Zähne an der Karte aus.


    In der Dom0 mit kernel-3.2.0 und Xen 4.1.3 funktioniert

    Code
    w_scan -f s -c DE -s S19E2 -o 7 > channels.conf


    mit dem media_build_bst_121102 von der DVBSky Homepage. In der DomU mit dem selben Kernel und funktionierendem PCI-Passthrough funktioniert es nicht. Ich bekomme immer wieder das hier:

    Code
    (time: 01:15) (time: 01:16) signal ok:
        	S  f = 10803 kHz H SR = 22000  5/6 0,35  QPSK
    Info: NIT(actual) filter timeout


    Ich glaube das heißt, ich habe keinen Empfang? ... kann ja nicht wirklich...


    In Dom0 und DomU sieht lspci gleich aus, module bauen läuft genauso durch. Bei beiden erscheint im dmesg immer mal wieder folgendes:

    Code
    cx23885_wakeup: 3 buffers handled (should be 1)


    bei der DomU ohne swiotlb jedoch immer "0 buffers handled", also ist mit
    swiotlb wohl "näher" am Dom0 Bild
    Einmalig bekomme ich in der DomU jedoch folgende Meldung im dmesg, wenn w_scan gestartet wird:

    Code
    videobuf_dma_map: videobuf_map_sg failed


    Danach zu googeln hat mich dann nicht mehr weiter, bzw. ans Ende meiner Fähigkeiten gebracht.
    Ich habe sogar mal den Aufruf von "videobuf_map_sg" in einem der Source-Pakete von DVBSky rausgepatcht, aber das brachte mir nur eine Kernel-Panik in der DomU nach make && make install && reboot....


    Ich scheue mich etwas, auch noch den "ganzen" vdr in der Dom0 zu installieren, ist ja nicht der Sinn und mit 7 anderen VMs (bei denen auch PCI-Passthrough funktioniert bei einem Sata-PCI-Controller und einem USB3.0-PCIe-Controller!) hab ich bisher so gut durchgehalten mit der Best Practice...


    Kernelparameter habe ich in der DomU schon folgende probiert:

    Code
    iommu=soft noirqdebug pci=nomsi swiotlb=128,force


    in vermutlich allen Kombinationen...
    Kernelparameter in der Dom0 waren in Variationen bis hin zu diesem Riesen:

    Code
    xen-pciback.permissive xen-pciback.hide=(00:02.0)(00:02.1)(00:08.0)(00:08.1)(02:00.0)(03:00.0) pci=resource_alignment='00:02.0;00:02.1;00:08.0;00:08.1;02:00.0;03:00.0' reassign_resources pci=routeirq swiotlb=256,force iommu=soft


    Zur Hardware: AMD Athlon 64 X2 5000 auf genauso altem Gigabyte-Board mit 8GB Ram... PCI-Passthrough funktioniert wie gesagt,

    Code
    cat /proc/cpuinfo|grep flags
    flags       	: fpu de tsc msr pae cx8 apic cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch hw_pstate


    Ich habe Ubuntu 12.10, Wheezy und Squeeze als DomU getestet, mal 64 und mal 32bit, mal 512 und mal 2048mb ram, mal eine und mal zwei VCPUs... so langsam klingt die Lösung in der Dom0 so schön einfach... Aber wer auch immer noch eine Idee hat, bitte her damit und vielen Dank! ;)


    MfGrooves, Bench

    Eine suuuuper Idee! Ich habe meinen Fli4l schon mit samba, pftp, vbox, fax, mldonkey usw schon weit ausgereizt (Jaja, ein Router ist ein Router...) und ein vdr_opt wäre die Kirsche auf der Sahnehaube :D
    Ich habe vor kurzem versucht, das alte opt_jukebox für die Fli4l Version 3.0.x umzusetzen, dies scheiterte jedoch an der nötigen Neukompilierung von ALSA für den 2.4.32-Kernel. Das Webinterface und der Player sind schon einsatzbereit, also fände ich es natürlich besonders super, wenn als nächstes das ALSA-Treiberpaket fertig werden würde. Als Tester für diesen Teil stelle ich mich jetzt schon bereit ;)
    Das gesamte Paket werde ich wohl erst bei Anschaffung einer DVB-S-Karte testen können... ;(


    Trotzdem schonmal danke für die Entwicklung!


    MfGrooves


    Bench