Debug Log Slow ioctl

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Debug Log Slow ioctl

      Hallo zusammen,

      ich betreibe mein UE 4K Box mit 2x QUAD LNB, OpenHDF 6.5, 2 Tuner belegt und ein USB Stick, im debug log wird sehr oft folgendes geschrieben:

      [!W!] dvb/frontend.cpp:1651 readFrontendData [eDVBFrontend] Slow ioctl 'FE_READ_SNR', potential driver issue, 64ms

      Was heißt das?
    • Salvatore schrieb:

      Hallo zusammen,

      ich betreibe mein UE 4K Box mit 2x QUAD LNB, OpenHDF 6.5, 2 Tuner belegt und ein USB Stick, im debug log wird sehr oft folgendes geschrieben:

      [!W!] dvb/frontend.cpp:1651 readFrontendData [eDVBFrontend] Slow ioctl 'FE_READ_SNR', potential driver issue, 64ms

      Was heißt das?


      Da steht doch, dass das etwas mit dem dvb Frontend und dessen Treiber zu tun hat. Wie man daraus ableiten kann, dass es etwas mit dem angesteckten USB Stick zu tun hat ist mir ein Rätsel.....
      Der Anfang einer Katastrophe ist eine beschissene Vermutung!

      (@EricBogosian als Travis Dane in Alarmstufe: Rot 2)

      Gewalt ist die letzte Zuflucht des Unfähigen. (Foundation Trilogie von Isaac Asimov

      amerikanischer Schriftsteller und Biochemiker

      * 02.01.1920, † 06.04.1992)
    • Wenn du keine Probleme siehst, würde ich die Meldung ignorieren.

      Was heißt die Meldung? ioctl heißt input output control. Das ist eine Methode, mit der Unix traditionell mit Geräten kommuniziert, hier wohl mit dem DVB Tuner (nicht mit dem USB-Stick). Der Aufruf der ioctl-Funktion hat länger gedauert als erwartet (erwartet werden maximal 35 ms).

      Wenn es Probleme gibt, sollten die E2-Programmierer ran, und diese Aufrufe vermeiden ...

      Bei kernel.org wird der ioctl Aufruf als deprecated=veraltet ("nicht mehr zu benutzen) gekennzeichnet: 6.1.2.2. FE_READ_SNR — The Linux Kernel documentation kernel.org/doc/html/latest/use…edia/dvb/fe-read-snr.html

      Im Image Quelltext github.com/openhdf/enigma2/blob/master/lib/dvb/frontend.cpp steht: "Neither the scaling nor the point at which the SNR is measured is defined in the API, leading to inconsistencies between tuners and need for tuner-specific code above to get values for signalQualitydB and signalQuality from the legacy API Where such code does not exist, those parameters have a high probability of being wrong." Wobei es hier nicht um Dauer des Aufrufs geht, sondern den Rückgabe-Wert. Grenzwert für die Dauer ist 35ms.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von buers ()

    • Quellcode

      1. 18:28:17.5179 { } /usr/lib/python2.7/site-packages/twisted/python/util.py:815 untilConcludes 2020-12-23 18:28:17+0100 [-] [SKIN] processing screen SlimChannelSelection:
      2. 18:28:17.5219 { E } /usr/lib/python2.7/site-packages/twisted/python/util.py:815 untilConcludes 2020-12-23 18:28:17+0100 [-] [SKIN] SKIN ERROR in screen 'SlimChannelSelection' widget 'widget': {XionHDF/skin.xml}: source 'primetime' was not found in screen 'SlimChannelSelection'!. Please contact the skin's author!


      Das würde ich eher für verdächtig halten.
    • Du hängst ein debuglog an, wo doch eigentlich ein crashlog vorhanden sein sollte.
      Klar kann ein SkinFehler der Grund sein für ein crash, muss aber auch nicht.

      Wir brauchen ein Crashlog.
      Wird nach jedem Crash automatisch erstellt und liegt im Home Verzeichnis.
      Die slow ioctl Geschichte ist völlig irrelevant, solche Sachen passieren immer mal wieder.
      10 mal Umschalten und dann hat man einige dieser Fehler, die sind aber nicht relevant und machen kein Crash.
      Allenfalls hat man ein verzögertes Umschaltverhalten oder einfach mal kein Bild.
      Aber die Box stürzt deswegen nicht ab.

      Grüße
    • Das Bild bleibt hängen oder gefroren und antwortet nicht mehr wenn man die Tasten auf die Fernbedienung drückt,
      das einzige was hilft ist Receiver aus- und wieder einschalten, ist das als crash zu bezeichnen?
      Wenn nicht sorry, hätte ich lieber Freezing schreiben sollen :)
      Auf jeden Fall wird kein Crashlog erstellt.
    • Dann crasht dein Receiver nicht.
      Das ist durchaus ein großer Unterschied.
      Durch dein wiederholtes "hartes" Ausschalten wirst du das Problem nur verschlimmern.
      Gründe deines Einfrieren können vielfältig sein.

      Da muss man ordentlich alles abarbeiten.
      Fehlersuche beginnt mit sorgfältig neu eingespieltem System ohne irgendwelche Wiederherstellung von Einstellungen.
      Alles neu einrichten.
      System beobachten ohne neue Plugins.
      Dann Schritt für Schritt deine Plugins hinzufügen und jedes mal gucken ob der Fehler auftritt.

      Dein beschriebenes Verhalten ist so nicht nachzuvollziehen und auch nicht zu erklären.
    • Ich habe das auch.

      Die Box crasht nicht, nur reagiert sie nicht mehr, bis der Fehler wieder weggeht. Das kann auch mal fünf Minuten dauern und das HDF-Logo links oben rotiert und rotiert und rotiert und rotiert... und die genannte Log-Zeile wird währenddessen einmal pro Sekunde ins Log geschrieben. Ist das mühsam? Ja, und vor allen Dingen nervig.

      Bei mir kommt das IMHO immer nur im Zusammenhang mit dem Tuner, wenn er auf einen Sender wechseln (vor, zurück, Sendernummer, egal wie) oder generell aktiviert werden soll (zB. im IPTV-Player in einem Stream auf Stop-Taste drücken). Dafür spricht auch die Erwähnung von der SNR im Fehler und das Quote von buers passt ja auch dazu. Allerdings passiert das nicht immer und ist auch nicht reproduzierbar.

      Im Kontext vom von buers verlinkten Source will die Box den Skin zeichnen und sich die SNR holen, was nicht geht. Hier müsste man das defensiver programmieren und entsprechend mit Timeouts hantieren oder eine etwaige Schleife drumherum einfach abbrechen und mal provisorisch ein "?" statt der echten Ratio hinschreiben. Wie auch immer: hier darf schlicht und einfach das Zeichnen des Skins nicht blockieren!

      Weil mal ehrlich, die SNR interessiert nur dann, wenn man die Schüssel einrichtet oder das Sendersignal ausbleibt, was auf die Lebenszeit der Box gerechnet verschwindend wenig ist.
    • Eigentlich ist "deprecated" (für den diskutierten ioctl-Call) noch strenger zu verstehen: "Bitte nicht mehr benutzen. Wenn du es benutzt und es passiert was unvorhergesehenes - selbst schuld". D.h. auch der von dir vorgeschlagene timeout ist eigentlich zu wenig, um sicher zu sein. Call vollständig vermeiden (wenn man es nicht wirklich besser weiß, für die konkrete Umgebung).

    Flag Counter