CineS2 v7A Probleme unter VMWare ESXi 6.5 in Ubuntu VM

    Hallo zusammen,


    was ist eigentlich aus dem Thema mit

    Code
    lnbh25_set_voltage(): I2C transfer error (-5)
lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    geworden?


    Habe von einer Cine S2 v5.5 (mit DuoFlex) wegen permanenten Bildfehlern auf eine v7A (mit der alten DuoFlex) gewechselt. Jetzt habe ich genau die gleichen "Fehler" im Log:



    Habe die Karte sowohl in meinem Server (Supermicro Board, ESXi 6.5, Ubuntu 16.04 VM) als auch im HTPC (MSI Board, Ubuntu 17.10) und aktuellstem stable Kernel

    Code
    uname -a
Linux vdr-wz 4.14.13-041413-generic #201801101001 SMP Wed Jan 10 10:02:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

    getestet und in beiden Systemen oben genannten "Fehler" erhalten.


    Die DVB Devices werden zwar angelegt

    Code
    /dev/dvb# ls -al
insgesamt 0
drwxr-xr-x  6 root root  120 Jan 13 19:48 .
drwxr-xr-x 20 root root 3920 Jan 13 19:48 ..
drwxr-xr-x  2 root root  120 Jan 13 19:48 adapter0
drwxr-xr-x  2 root root  120 Jan 13 19:48 adapter1
drwxr-xr-x  2 root root  120 Jan 13 19:48 adapter2
drwxr-xr-x  2 root root  120 Jan 13 19:48 adapter3

    Aber Adapter0 bekommt garkeine Sender rein, Adapter 1 scheint zu funktionieren.


    Eine ddbridge.conf mit msi=0 oder msi=1 habe ich sowohl auf dem Server als auch im HTPC versucht, brachte aber leider keine Verbesserung.


    PCIe Steckplätze habe ich auch schon getauscht, leider ebenfalls ohne Erfolg. Stromkabel ist lediglich an der Duoflex angeschlossen, da ich einen Multiswitch habe.


    Hat jemand eine Idee was ich hier machen kann bevor ich mich an den Digital Devices Support wende?


    Danke,

    Alex

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Zitat von Honker

    was ist eigentlich aus dem Thema mit

    Code
    lnbh25_set_voltage(): I2C transfer error (-5)
lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    geworden?

    Das ist KEIN(!) Fehler bzw. in irgendeiner Form ein Problem, solange darauf

    Zitat von Honker
    Code
    [   11.624073] i2c i2c-0: lnbh25_attach(): attached at I2C addr 0x08

    kommt. Das ist Teil des Probings des LNB Controllers auf zwei I2C Adressen. Wenn auf der ersten getesteten kein LNBH25 zu finden ist, poppt eben der I2C transfer error im Kernel Log auf. Ähnliches passiert übrigens auch beim STV0910 Demodulator - der kann je nach Hardware auf zwei unterschiedlichen Adressen zu finden sein. Wenn bei entsprechender Hardware auf der ersten nichts zu finden ist, gibts ein STV0910 I2C Error im Kernel Log.


    Solange am Ende der Initialisierung steht, dass die Frontends (ST STV0910) registriert wurden, ist alles in Ordnung. Im Umkehrschluss bedeutet das aber auch, dass speziell Dein Problem mit dem ersten Tuner woanders zu suchen ist (und ich wüsste offen gesagt nicht wo; der gesamte Treiberstack ist bei sehr vielen Leuten fehlerfrei und im Dualtuner-Betrieb im Einsatz - evtl. Hardwareproblem?).

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

    Zitat von nst

    Das ist KEIN(!) Fehler bzw. in irgendeiner Form ein Problem,....

    Alles klar, danke für die Info. Hatte schon rumgesucht, aber noch nirgends eine definitive Aussage dazu gefunden.


    Habe die TV Karte jetzt mal wieder in der Server eingebaut. Jetzt macht Adapter 1 die selben Probleme wie zuvor Adapter 0.


    Ist schon irgendwie merkwürdig. Die v5.5 konnte wenigstens auf alles Tunern einen "Lock" bekommen.


    Irgendjemand eine Idee was das sein könnte?


    Und im Syslog dann

    Code
    Jan 14 13:42:42 vdr vdr: [1237] frontend 1/0 timed out while tuning to channel 2 (ZDF HD), tp 111361

    Grüße,

    Alex


    Edit: Wenn ich die Duoflex Karte abklemme, dann gehen beide Adapter...

    Code
    dvb-fe-tool --femon -a0 -f0
Lock   (0x1f) Signal= -33,74dBm C/N= 18,30dB preBER= 0
Lock   (0x1f) Signal= -33,75dBm C/N= 18,30dB preBER= 0
Lock   (0x1f) Signal= -33,75dBm C/N= 18,40dB preBER= 0

dvb-fe-tool --femon -a1 -f0
Lock   (0x1f) Signal= -33,01dBm C/N= 16,60dB preBER= 0
Lock   (0x1f) Signal= -32,99dBm C/N= 16,60dB preBER= 0
Lock   (0x1f) Signal= -32,98dBm C/N= 16,70dB preBER= 0

    Edit 2: Nachdem ich ein

    Code
    pciPassthru0.msiEnabled = "FALSE"

    in der VM wieder hinzugefügt habe, scheinen alle 4 Adapter zu funktionieren.


    Komischerweise wurde anders als bei der v5.5 die v7 aber auch ohne diese Einstellungen erkannt, weshalb ich diese jetzt beim Einbau der v7 weggelassen habe.


    Edit 3: Ich muss das korrigieren. Nach kurzer Zeit sind beide neuen Adapter (v7) nicht mehr ansprechbar und im Log finde ich dann

    Code
    Jan 14 19:36:55 vdr vdr: [6686] frontend 0/0 timed out while tuning to channel 1 (Das Erste HD), tp 111493

    Erst nach einem reboot der VM geht Adapter0 dann wieder, Adapter 1 weiterhin nicht. Irgendwer eine Idee was das sein kann?


    Edit4: Habe nach einem Reboot der VM eine Aufnahme auf Adapter 0 gestartet, die auch durchlief und laut vdr-checkts auch keine Fehler hatte. Nachdem die Aufnahme fertig war, scheint der VDR jetzt keinen Zugriff mehr auf Adapter 0 zu bekommen. Im Log finde ich jetzt lauter

    Code
    an 14 21:52:55 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 185 (Aristo.TV), tp 111273
Jan 14 21:53:16 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 2 (ZDF HD), tp 111361
Jan 14 21:53:37 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 1 (Das Erste HD), tp 111493
Jan 14 21:53:58 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 9 (PHOENIX HD), tp 111582
Jan 14 21:54:40 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 229 (Dlf Kultur), tp 111953
Jan 14 21:56:04 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 290 (Radio Freundes-Dienst), tp 112515
Jan 14 21:56:25 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 55 (WDR HD Aachen), tp 112604
Jan 14 21:57:07 vdr vdr: [1365] frontend 0/0 timed out while tuning to channel 87 (CNBC Europe), tp 211597

    Wie hier schon jemand schrieb, hilft es dann den Treiber zu entladen und neu zu laden. Der VDR hat dann wieder Zugriff auf die Adapter. Habe bis auf das live Plugin keine weiteren Plugins während der Tests geladen.


    Edit 5: Habe nochmal die VM neu gestartet und dann mit dvb-fe-tool auf den Adapter geschaut was passiert. Nach ziemlich genau 20 Minuten verliert der VDR den Lock auf den Adapter:

    Code
    Jan 14 22:28:31 vdr vdr: [1309] frontend 0/0 timed out while tuning to channel 38 (Franken Fernsehen HD), tp 110714

uptime
 22:29:59 up 22 min,  2 users,  load average: 0,15, 0,24, 0,19

    Due DuoFlex geht zu dem Zeitpunk aber weiterhin:

    Code
    root@vdr:/# dvb-fe-tool --femon -a2 -f0
Lock   (0x1f) Signal= 75,00% C/N= 36,00% postBER= 1
Lock   (0x1f) Signal= 76,00% C/N= 36,00% postBER= 1
^CLock   (0x1f) Signal= 76,00% C/N= 36,00% postBER= 1
ERROR    FE_SET_VOLTAGE: Vorgang nicht zulässig

root@vdr:/# dvb-fe-tool --femon -a3 -f0
Lock   (0x1f) Signal= 76,00% C/N= 33,60% postBER= 0
Lock   (0x1f) Signal= 76,00% C/N= 33,80% postBER= 0
^CERROR    FE_SET_VOLTAGE: Vorgang nicht zulässig

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    8 Mal editiert, zuletzt von Honker ()

    Habe sicherheitshalber den VDR nochmal neu gebaut, um auch hier Probleme auszuschließen. Brachte jedoch auch keinen Erfolg. Diesmal war nach einem Reboot Adapter 0 nahezu (unter 5 Minute) für den VDR weg. Adapter 1 habe ich zur zeit per udev Regel deaktiviert.


    Werde heute Abend mal ohne angesteckte DuoFlex testen, ob der VDR dann ebenfalls den Zugriff auf den/die Adapter von der v7 verliert.

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Habe mit der abgeklemmten DuoFlex das selbe Problem.


    Habe eine Aufnahme programmiert und wenn der VDR dann versucht auf die Karte zuzugreifen, bekommt er ein timeout:


    Wenn ich dann den VDR stoppe, ddbridge entlade, neu lade und den VDR wieder starte, hat der VDR wieder Zugriff auf den Adapter.


    Habe schon SAT Kabel zwischen den Adaptern getauscht, hat aber auch keine Verbesserung gebracht...

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Es ist und bleibt frustrierend...


    Auf dem selben Server in einer Windows VM mit DD Treibern von der Webseite und der DD-TV Software scheint es keine Probleme zu geben, 2 parallele Aufnahmen sind mit der v7A scheinbar problemlos möglich.


    Ubuntu 16.04.3 Bare Metal auf dem selben Server mit Kernel 4.14.15 scheint auch problemlos zu laufen.


    Ubuntu 16.04.3 als VM funktioniert einfach nicht, egal welches Setting ich versuche, ich bekomme immer ein "frontend timed out..."

    • BIOS 2.0a, Kernel 4.14.13, DDBridge aus Kernel 0.9.31
    • BIOS 2.0a, Kernel 4.4.0-109, DDBridge von Git 0.9.32
      • ESXi Energierichtlinie hoch
      • ESXi Energierichtlinie hoch, BIOS: Power Technology -> disabled
      • ESXi Energierichtlinie hoch, BIOS: Power Technology -> custom, alle Optionen -> disabled
      • ESXi Energierichtlinie hoch, BIOS: Power Technology -> disabled, PCIe Port - Gene X -> Gen1
    • BIOS 2.2c, Kernel 4.14.13, DDBridge aus Kernel 0.9.31
    • BIOS 2.2c, Kernel 4.14.13, DDBridge aus GIT letzter Stand 0.9.32+
    • BIOS 2.2c, Kernel 4.15.rc9, DDBridge aus GIT letzter Stand 0.9.32+
      • BIOS: Detect Non-Compliance Device -> Enabled
      • BIOS: PCIe Port -> Enabled, PCIe Port - Gene X -> Gen1, Detect Non-Compliance Device -> Enabled

    Mit den neusten Treibern habe ich aber zumindest kein

    Code
    lnbh25_set_voltage(): I2C transfer error (-5)
lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    mehr im Log



    Es scheint kein prinzipielles Hardwareproblem zu sein, da es Bare Metal und in einer Windows VM läuft.

    Es scheint kein prinzipielles ESXi Problem zu sein, weil es in einer Windows VM läuft.


    Wieso kann der VDR nach einem neu Laden der ddbridge Module wieder auf die Karten zugreifen?


    Und ich scheine nicht der Einzige zu sein der Probleme mit der neuen v7A unter ESXi hat, sie hier und hier.


    Hat vielleicht noch irgendjemand eine helfende Idee? Werde sonst auch mal den Digital Devices Support bemühen.


    Danke,

    Alex

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Dein Problem hat nichts mit dem ddbridge Kernel-Merge Projekt zu tun, bitte mach dazu einen eigenen Thread auf. Danke.


    EDIT: Kann evtl. ein Mod entsprechend splitten?

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

    Wie angefragt ausgelagert.


    Honker


    Threadtitel evtl. nach Wunsch anpassen.


    Regards

    fnu

    HowTo: APT pinning

    fnu Danke!

    Honker Es wäre mal interessant, was sich in Deinem Kernel-Log abspielt, wenn Dein VDR Probleme bekommt (da wird Dich der DD-Support garantiert auch nach fragen). Ich würde das mit dddvb (hast Du schon installiert) nochmal reproduzieren und das dann dem Support mitteilen.


    Nebenbei, statt

    Zitat von Honker

    Mit den neusten Treibern habe ich aber zumindest kein

    Code
    lnbh25_set_voltage(): I2C transfer error (-5)
lnbh25_attach(): no LNBH25 found at I2C addr 0x0c

    mehr im Log

    kommt halt jetzt

    Zitat von Honker
    Code
    [    5.413137] lnbh25: i2c_write error
[    5.414410] LNBH25 on 08

    was so ziemlich denselben Hintergrund hat :) Bitte - gilt auch für alle anderen Mitleser - den Firlefanz einfach ignorieren.


    EDIT: Formatierung.

    Server: Gigabyte P35-DS4, Intel Core2Duo E6850, 4GB DDR2-RAM (Headless), Gentoo Linux x86_64 / Kernel 4.16.7 / DD CineCTv6+DuoFlex C/T/T2+DuoFlex C/C2/T/T2 w/Kernel Stock Drivers / TVHeadend-GIT-3356759d8

    HTPC: ASRock J5005-ITX (Intel Pentium Silver J5005, 1.5GHz), 8GB SO-DDR4, Intel UHD Graphics 605 in Antec Fusion Remote Black+SoundGraph iMON LCD ( 0038 ), Kodi v18 Leia
    SW: Kodi Krypton+Leia auf allerlei Gerätchen (HTPC: VAAPI+HD-Audio+LCDproc addon / Ubuntu Bionic 18.04 (x86_64), RPi2, NVIDIA Shield Android TV, Wetek Play 1@LibreELEC/NAND, Tablets, Smartphones, Win/Mac/Linux Desktops)

    Honker hast Du das auch schon probiert?

    Zitat von crow

    Honker hast Du das auch schon probiert?

    Ja, hat aber leider keine Verbesserung gebracht. Bei meiner alten V5.5 musste ich die Option zwingend aktivieren, da es sonst Timeouts gab.

    Zitat von nst

    Honker Es wäre mal interessant, was sich in Deinem Kernel-Log abspielt, wenn Dein VDR Probleme bekommt (da wird Dich der DD-Support garantiert auch nach fragen). Ich würde das mit dddvb (hast Du schon installiert) nochmal reproduzieren und das dann dem Support mitteilen.

    Im kernel.log herrscht zu dem Zeitpunkt absolute Stillte. Es gibt darin leider überhaupt keinen Hinweis.


    Habe mal die debug Option vom dvb_core Modul aktiviert. Aber auch das gibt keine Auskunft was in dem Moment passiert.


    Kennt noch jemand andere Möglichkeiten um an Debug Logs zu kommen?


    Grüße,

    Alex

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Auch wenn ASPM im Bios deaktiviert ist, habe ich mal grub die Option

    Code
    pcie_aspm=off

    mitgegeben. Leider ohne Erfolg.


    Zusätzlich habe ich auch nochmal in der Datei /etc/modprobe.d/ddbridge.conf msi deaktiviert, hat aber auch nichts gebracht.

    Server: Supermicro X9SAE, Intel Xeon E3-1245v2, ESXi 6.5

    VDR VM: Ubuntu 16.04 LTS, 2x DD Cine S2, VDR 2.3.8

    Einmal editiert, zuletzt von Honker ()

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden