ddbridge - drxk - digital devices duoflex c/t - probleme in dmesg: "drxk: Error -5"

  • Ich habe es jetzt auch geschafft, die Karte in diesen "Error -22" Zustand zu versetzen.


    Offenbar funktioniert DVB-T nicht mehr, sobald man das DVB-C Frontend einmal geöffnet hatte.
    Da ist offensichtlich irgendwo der Wurm drin...


    Momentan hilft nur Neuladen des Treibers.


    CU
    Oliver

  • OK, dann versetzt also irgendein dienst meine karte in den DVB-T modus, obwohl ich nur dvb-c nutzen will.


    Zum neuladen des Treibers reiht da

    Code
    1. sudo rmmod drxk

    oder muß ich dd-bridge auch neu laden?


    Denn nach einem unload und reload der module erscheint beim w_scan wieder wie gewohnt


    usw.

  • OK, dann versetzt also irgendein dienst meine karte in den DVB-T modus, obwohl ich nur dvb-c nutzen will.


    Zum neuladen des Treibers reiht da

    Code
    1. sudo rmmod drxk

    oder muß ich dd-bridge auch neu laden?


    drxk kann nur entladen werden, wenn man ddbridge zuvor entladen hat. (ddbridge benötigt drxk.)


    Quote


    Denn nach einem unload und reload der module erscheint beim w_scan wieder wie gewohnt


    usw.


    Error -5 kann ich - im Gegensatz zu Error -22 - nicht reproduzieren. ;(


    Bei Error -5 tippe ich nach wie vor auf ein Problem mit dem I2C-Bus.


    Hinweis:
    Sicherheitshalber solltest Du das nicht benötigte DVB-T Frontend wegräumen[1], bevor Du eine DVB-Applikation startest:

    Code
    1. rm /dev/dvb/adapter0/frontend1
    2. rm /dev/dvb/adapter1/frontend1


    CU
    Oliver


    P.S.:
    [1] Hoffe, daß sich diese Problem bald erledigt (Erweiterung des DVB-API).

  • Moin!


    P.S.:
    [1] Hoffe, daß sich diese Problem bald erledigt (Erweiterung des DVB-API).


    Das hoffe ich auch, es war aber lange nichts mehr von Manu auf der ML zu lesen...


    Eine Frage/Bitte hätte ich:
    Wäre es möglich, an die Frontends (bzw. alle DVB-Devicenodes) ein udev-Attribut zu hängen, damit man sie in udev-Regeln leichter unterscheiden kann?
    Das einzige, was sich unterscheidet, ist die Adapter-Nummer und die kann sich ändern, falls ein anderer Treiber zuerst geladen wird.
    Ich weiß, dass es den Modul-Parameter "adapter_nr" gibt, aber den müsste man dann bei jedem Treiber, den man benutzt, angeben.
    Vielleicht sowas wie "dd_port=0.0.0" für den ersten Tuner am ersten Port der ersten ddbridge und "dd_port=0.0.1" für den zweiten Tuner am ersten Port usw.


    Lars.

  • OK, wenn ich die module entferne, neu lade und dann nochmal nen w_scan mache verändert sich die art der Fehlermeldung ein wenig:



    ich werde jetzt den Treiber ein letztes mal auf dem Atom Board neu kompilieren und schauen obs dann weg ist. Wenn nicht, werde ich die Karte nochmal in meinen i3 bauen und das Ergebnis hier posten!

  • So, ich habe die Karte umgebaut und in dem i3 funktioniert alles auf Anhieb (bis auf den fehlerhaften checkout der saa7... Treiber aus dem repo - was ja hier egal ist).


    Alles funzt und ich wundere mich wo auf einmal das Problem in meinem Ion-Atom PVR herkommt, dass die KArte dort die obigen Fehler auswirft. :(

  • Moin!



    Das hoffe ich auch, es war aber lange nichts mehr von Manu auf der ML zu lesen...


    Submitted ist die Erweiterung. Ob oder wann sie endlich eingecheckt wird, ist eine ganz andere Frage.
    Der Subsystem-Dikt^WMaintainer macht ja bekanntlich einfach, was er will.


    Quote


    Eine Frage/Bitte hätte ich:
    Wäre es möglich, an die Frontends (bzw. alle DVB-Devicenodes) ein udev-Attribut zu hängen, damit man sie in udev-Regeln leichter unterscheiden kann?
    Das einzige, was sich unterscheidet, ist die Adapter-Nummer und die kann sich ändern, falls ein anderer Treiber zuerst geladen wird.
    Ich weiß, dass es den Modul-Parameter "adapter_nr" gibt, aber den müsste man dann bei jedem Treiber, den man benutzt, angeben.
    Vielleicht sowas wie "dd_port=0.0.0" für den ersten Tuner am ersten Port der ersten ddbridge und "dd_port=0.0.1" für den zweiten Tuner am ersten Port usw.


    So etwas ließe sich nur mit einer treiberspezifischen Erweiterung realisieren. Das DVB-Framework gibt das nicht her.
    Werde mir anschauen, wie aufwendig es ist. Vermutlich immer noch einfacher als etwas auf der ML durchzusetzen...


    CU
    Oliver

  • So, ich habe die Karte umgebaut und in dem i3 funktioniert alles auf Anhieb (bis auf den fehlerhaften checkout der saa7... Treiber aus dem repo - was ja hier egal ist).


    Alles funzt und ich wundere mich wo auf einmal das Problem in meinem Ion-Atom PVR herkommt, dass die KArte dort die obigen Fehler auswirft. :(


    Damit ist zumindest klar, daß die Karte in Ordnung ist. Allerdings sehr merkwürdig das ganze.


    CU
    Oliver

  • Moin!



    Submitted ist die Erweiterung. Ob oder wann sie endlich eingecheckt wird, ist eine ganz andere Frage.
    Der Subsystem-Dikt^WMaintainer macht ja bekanntlich einfach, was er will.


    Ja, das dvb/v4l-Subsystem ist eine interessante Landschaft und das Lesen der ML kann man manchmal nur mit einem guten Bier ertragen. :prost1



    So etwas ließe sich nur mit einer treiberspezifischen Erweiterung realisieren. Das DVB-Framework gibt das nicht her.
    Werde mir anschauen, wie aufwendig es ist. Vermutlich immer noch einfacher als etwas auf der ML durchzusetzen...


    Vermutlich... Danke dafür!


    Lars.

  • Moin!



    Ja, das dvb/v4l-Subsystem ist eine interessante Landschaft und das Lesen der ML kann man manchmal nur mit einem guten Bier ertragen. :prost1


    Das hat mit Spaß nichts mehr zu tun. Ich denke darüber nach, wie man Treiber am besten außerhalb des Kernels maintainen könnte. Ich habe keine Lust mehr, mich mit diesem Kerl noch länger auseinander zu setzen. :§$%


    CU
    Oliver

  • Moin!


    Ich bin eigentlich nur ein stiller Mitleser, weil ich mich als Anwendungsentwickler auf dem Laufenden halten möchte.
    Aber was da so manchmal abgeht... Aber wir driften ab. :)


    Lars.

  • Das hat mit Spaß nichts mehr zu tun. Ich denke darüber nach, wie man Treiber am besten außerhalb des Kernels maintainen könnte. Ich habe keine Lust mehr, mich mit diesem Kerl noch länger auseinander zu setzen.


    Im Zusammenhang mit dem Basteln an Vtuner habe ich schon mal überlegt ob cuse ein Weg sein könnte. Der mrec von Sundtek hat damit wohl nicht so gute Erfahrungen gesammelt, aber es scheint wohl auch schon länger her zu sein. Leider verstehe ich von den DVB-Treibern kaum etwas, deshalb habe ich das Wagnis bisher gescheut damit mal zu experimentieren.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Im Zusammenhang mit dem Basteln an Vtuner habe ich schon mal überlegt ob cuse ein Weg sein könnte. Der mrec von Sundtek hat damit wohl nicht so gute Erfahrungen gesammelt, aber es scheint wohl auch schon länger her zu sein. Leider verstehe ich von den DVB-Treibern kaum etwas, deshalb habe ich das Wagnis bisher gescheut damit mal zu experimentieren.


    Vtuner finde ich ein interessantes Konzept, allerdings weniger in diesem Zusammenhang. Mir geht es auch nicht darum, binary-only Treiber zu bauen, was imho ohnehin der falsche Weg ist.


    Wenn ich etwas Zeit habe, werde ich Vtuner über Weihnachten austesten. Bei Bedarf eine Servermaschine zu starten und sich deren DVB-Karte auszuleihen, finde ich genial. Allerdings muß das ganze so zuverlässig über das LAN funktionieren, als ob die Karte lokal eingebaut wäre...


    Treiber im Userspace sind möglich, allerdings benötigt man dennoch ein Kernelmodul, was den Datentransfer z.B. über den PCIe-Bus macht. So etwas würde ebensowenig wie Vtuner im Kernel akzeptiert. Frontend-Treiber in Userspace wären dagegen kein Problem, denn auf den I2C-Bus kann man zugreifen.


    Langsam ist es an der Zeit, daß man den Leuten, die an gewissen Schaltstellen sitzen und mauern, einmal in den Hintern tritt. Letztendlich sollte der Nutzen für den Anwender entscheidend sein. Wenn die Qualitätsansprüche, die auf der ML gegen Vtuner ausgegraben wurden, auch bei normalen Treibern gelten würden, wären höchstens 1/3 der aktuellen Treiber im Kernel... :motz3


    CU
    Oliver

  • Mir geht es auch nicht darum, binary-only Treiber zu bauen


    Mir auch nicht. Nur weil es geht muss man es nicht unbedingt machen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Moin!


    Ich finde diese Diskussion, dass man z.B. vtuner auch komplett im Userspace abhandeln könnte, irgendwie fruchtlos. Sie wollen anscheinend nicht kapieren, dass das eine super Lösung wäre, um eben nicht alle möglichen Anwendungen anpassen zu müssen. Und wer der Meinung ist, DVB-Streams über eine Satelliten-Internetverbinung schicken zu müssen... Naja.
    Und LD_PRELOAD ist eigentlich auch keine Lösung, sondern ein noch böserer Hack als vtuner... Außerdem funktioniert es spätestens dann nicht mehr, wenn man mehrere Libs laden muss/möchte.


    Und dann immer dieses Gejammer, man würde Closed-Source-Treibern Tür und Tor öffnen... Als ob das jetzt nicht auch schon geht mit einem eigenen Kernelmodul. Und sowas lässt sich ja auch leicht über so was wie DKMS bauen.


    Ja, ich denke auch, der Nutzer/Nutzen sollte mehr im Vordergrund stehen.


    Lars.

  • LD_PRELOAD ist eine optimale Zwischenlösung bis eine DVB Bibliothek kommt (und so ist es bei uns auch angedacht, bei MacOSX wird dieser Mechanismus z.B nicht verwendet). Der eigentliche Treiber hat mit diesem Modul bei uns nichts zu tun.


    Mittels vfio sollte es auch möglich sein PCI Treiber im Userspace implementieren zu können.
    CUSE ist lediglich auf FreeBSD brauchbar, die Linux Implementierung ist nicht konsistent.


    Treiber unter Linux auf Applikationslevel sind ganz klar die Zukunft, insbesondere da diese (sofern sie gut designed wurden) auch Betriebssystem-übergreifend funktionieren. Innerhalb der nächsten Jahre wird sich hier noch so einiges tun.

  • Um nochmal auf das eigentliche Problem zurück zu kommen.
    Ich habe jetzt nochmal alles frisch neu gemacht und mittlerweile sieht die ausgabe nach dem systemstart wie folgt aus:




    ich weiß nicht was da falsch ist.. aber das mit dem doppelten pci device ist strange...

  • Welcher Treiberstand, welcher Kernel, welche Distribution werden eingesetzt?


    CU
    Oliver

  • Welcher Treiberstand, welcher Kernel, welche Distribution werden eingesetzt?

    Es handelt sich nach wie vor um ein Ubuntu mittlerweile Version 12.04 in 64bit. - Also Kernel 3.2.0-26-generic x86_64.
    Erst habe ich die Treiber aus dem yavdr repo genutzt, und dann mei der fehlermeldung nochmal selber frisch kompiliert, bei beiden führt das zu einem "flood" von dmesg im 2 Sek. Rhytmus mit der "kernel: [ 2823.788102] drxk: Error -22 on GetLockStatus". Die Firmware ist auch extra nochmal frisch installiert worden...
    Oben im Kernel-Log steht diese Version:
    DRXK driver version 0.9.4300
    Ich habe sogar das Flachbandkabel ausgetauscht, um das ausschließen zu können...

  • Also, seltsam finde ich, dass da immer noch steht "could not load firmware file..." ich habe die Datei frisch extrahiert und nach /lib/firmware kopiert, den owner auf root:root gesetzt und rw:r:r als rechte verteilt.


    Sonst hat das doch immer gereicht? Oder was könnte noch das laden der Firmware verhindern?