dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1

    hi,


    habe gerade eine karte zum richten hier, die die meldung bringt:
    "dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1"


    ansonsten funktioniert die karte, sprich empfang ist da, ton und video out
    klappt, bis eben auf das osd. es handelt sich um eine 1.3er.


    habe bereits verschiedene pci slots, rechner, kernel versionen (2.6.20, 2.6.18,
    2.4.31) und firmwares entsprechende versucht.
    kann hier evtl. ein defekt des dpram und/oder saa7146 vorliegen?
    das osd ram (2mb, links unter av7111) ist bereits erfolglos getauscht.


    was koennte das noch sein?



    danke & gruss,
    -- randy

    Hi,


    hasst du es mal mit einer neu aufgebauten setup.conf versucht? Nicht, dass da irgendeine skin-Einstellung ist, die nur mit 4MB sauber funktioniert. Ich hatte eine Weile solche Meldungen, wenn SingleArea8bpp in Skinenigma aktiv war.


    Gruss

    vdr-2.6.7

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver
    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Also ich hatte den Fehler auch in Verbindung mit firmware-load fehlern.


    Bei mir lags definitiv am geshareten IRQ.
    Tauchte erst auf, als ich ne 2. Karte dazusteckte, dann hab ich pci`s getauscht und es ging wieder.
    Dann kam der Fehler plötzlich, wenn meine lankarte am arbeiten war(aber auch nur bei viel durchsatz). Jetzt hab ich noch mal getauscht und es scheint nun alles zu gehen.

    Den Fehler habe ich auch des oefteren mit ner 1.5er .
    Naja , eigentlich nur wenn ich am debuggen bin und VDR dank eines
    Segfault abschmiert.
    Die ist aber definitiv nicht defekt.


    Bei mir spukt er dann immer noch was aus , was sich auf die Zeile aus dvbosd.c bezieht :
    class cDvbOsd : public cOsd {
    private:
    int osdDev;
    int osdMem;
    bool shown;
    void Cmd(OSD_Command cmd, int color = 0, int x0 = 0, int y0 = 0, int x1 = 0, int y1 = 0, const void *data = NULL);


    Hilft dann nur Ent/-Neuladen von Treiber.
    Im Normalbetrieb passiert es aber net....
    Na sehr hilfreich.. ;)

    naja, mich wundert halt nur, das es genau diese eine karte ist, die auch bei dem
    besitzer defekt ist, und viele andere karten wunderbar bei mir (vor und nach reparatur ;))
    im rechner laufen. daher denke ich schon, das zumindest hier ein hardwarefehler der
    karte vorliegt.
    weiss leider nicht, wie ich sowas noch tiefer debuggen koennte, ausser auf shared irqs
    achten und verschiedene treiber/vdr binaries testen...


    -- randy


    Wenn das Problem nur mit genau dieser einen Karte auftritt, wird sie schon irgendeinen HW-Defekt haben...


    Funktioniert denn eine Aufzeichnung über die Karte bzw. Wiedergabe einer Aufzeichnung?
    Steht was von ARM crashes im Log?


    CU
    Oliver

    Zitat

    Original von randy
    mhm, muss ich nachher noch testen, danke fuer den hinweis;
    ich weiss nur, das wenn man umschalten will ein arm crash passiert; treiber reload
    und dann kommt wieder livebild mit dem LoadBitmap timeout.


    kann man bei einem arm crash mehr debug infos kriegen?


    Nicht direkt. Ein ARM-Crash _könnte_ auf ein defektes DRAM hinweisen, da der ausführbare Code im DRAM liegt (und teilweise auch im DPRAM). Im SDRAM liegt dagegen kein ausführbarer Code, ein Fehler hier ist eher unwahrscheinlich.


    Afaik wird reines Live-Schauen direkt von der HW erledigt, d.h. die eigentliche ARM-CPU hat damit nicht viel zu tun. Umgekehrt, wenn es bei Wiedergabe oder Aufnahme einen Crash gibt, dann deutet dies eher in Richtung ARM-CPU und die Peripherie, die zur Programmausführung benötigt wird.


    CU
    Oliver

    Moin,
    bin gerade dabei von Kernel 2.4.27 und VDR 1.3.24 aufzurüsten. Habe jetzt fast genau die gleiche meldungen, allerding nur beim abspielen. Wenn ich zuruckschalte auf der alte installation dann gibt es keine fehler. D.h. meine karte scheint auch nicht kaputt zu sein:



    Bin auch ein bisschen ratlos. Vielleicht werde ich die beiden karten vertauschen.


    MfG Brian

    Cheers Brian


    Intel Dual Core, Asus P8H67-V, 4GB Ram, Easy VDR 14.04 Headless, 4 Tuner Cine2, Astra 19.2E & Astra 28.2E (BBC), XVDR zu 3 * KODI Clients (2 x Rasb Pi) über XVDR

    Einmal editiert, zuletzt von Briandorling ()

    Es scheint kein HW-defekt zu sein.
    Denn bei mir kommt die Meldung auch seit ca. zwei Wochen.


    Dort habe ich auf UFO's HG-Driver gewechselt, gleichzeitig aber auch VDR1.6.0 inkl. Plugin-Updates und neuer Kernel 2.6.25-rc8.


    Auch bei mir hilft nur Treiber neu laden (oder restart).


    Edit:
    Hab nur eine PCI-Slot (EPIA) und nur eine Karte drin.

    Moin, plugins habe ich nur mp3, mplayer und Femon.
    Cheers

    Cheers Brian


    Intel Dual Core, Asus P8H67-V, 4GB Ram, Easy VDR 14.04 Headless, 4 Tuner Cine2, Astra 19.2E & Astra 28.2E (BBC), XVDR zu 3 * KODI Clients (2 x Rasb Pi) über XVDR

    Hi,


    im Log oben sind vermutlich die "DEBI irq oops", d.h. zu diesem Zeitpunkt unerwartete Interrupts, die Ursache des Problems.


    Tritt das Problem auch mit Firmware F12623 auf?
    Passiert das nur mit dem Full-TS/Refactoring-Treiber auf oder auch mit dem "normalen" HG-Treiber?
    Verwendet jemand ein Mehrprozessorsystem (SMP) oder Riser-Karten?


    CU
    Oliver

    Hi UFO,


    bei mir tritt es nur sehr sporadisch auf. Das letzte mal war gestern abend.
    Habe auf Standart-Kernel-Treiber umgestellt und gebe Bescheid, sobald sich was tun - oder eben nicht.


    P.S.: Firmware F12623 und ohne PCI-Riser und kein SMP.

    Zitat

    Original von CR7
    Hi UFO,


    bei mir tritt es nur sehr sporadisch auf. Das letzte mal war gestern abend.
    Habe auf Standart-Kernel-Treiber umgestellt und gebe Bescheid, sobald sich was tun - oder eben nicht.


    P.S.: Firmware F12623 und ohne PCI-Riser und kein SMP.


    Wenn es nur sporadisch auftritt, ist ein Vergleich natürlich schwieriger...
    Steht da auch was von "DEBI irq oops" im Log?


    CU
    Oliver

    Zitat

    Original von randy
    hallo,


    hab den effekt mit dem standard skin. daher denke ich nicht das es durch falsches osdmem
    geschieht. vorallem muesste dann doch der fehler "not enough mem" kommen, oder?


    -- randy


    gibt es Empfehlungen, was man tunlichst vermeiden sollte? Die neueste muggle-Version hat dieses Problem gerne. Wenn ich den Treiber neu lade, geht es wieder für eine Weile. Wenn ich den Rechner ausschalte, ist es danach wesentlich stabiler als nach nur Treiberneuladen, das müsste ich aber noch besser testen. (CanHandleArea gibt sein OK, von daher kein Problem, ich reduziere einfach meine Anforderungen, bis CanHandleArea das akzeptiert)


    Kernel 2.6.25
    Apr 15 08:15:05 server kernel: dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623

    UFO,


    bei mir tritt der OOPS auf:

    Code
    Apr 15 21:12:36 brian kernel: DEBI irq oops @ 514305, psr:0x00040728, ssr:0x00805020                                    
Apr 15 21:24:57 brian kernel: DEBI irq oops @ 699576, psr:0x00040628, ssr:0x00805030                                    
Apr 15 21:24:57 brian kernel: dvb-ttpci: GPIO0 irq oops @ 699577, psr:0x000c0720, ssr:0x00805030


    Ohne PCI-Riser und kein SMP.


    Firmware dvb-ttpci-01.fw-2622, ich habe einen FW 12623 nirgends gefunden.


    >>Passiert das nur mit dem Full-TS/Refactoring-Treiber auf oder auch mit dem "normalen" HG-Treiber?


    Ich habe kein Full-TS treiber installiert.

    Cheers Brian


    Intel Dual Core, Asus P8H67-V, 4GB Ram, Easy VDR 14.04 Headless, 4 Tuner Cine2, Astra 19.2E & Astra 28.2E (BBC), XVDR zu 3 * KODI Clients (2 x Rasb Pi) über XVDR

    Zitat

    Original von Briandorling
    ich habe einen FW 12623 nirgends gefunden.


    Gibt es hier: http://vdrportal.de/board/thread.php?threadid=59746&hilight=f12623


    CU
    Oliver

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden