Posts by UFO

    Der Jumper befindet sich in der Nähe des schwarzen Steckverbinders auf der rechten Seite der Karte. (Auf dem Bild im Shop ist er nicht bestückt.)


    Es könnte natürlich sein, dass es einen neue Revision der Karte gibt. Da muss dann der Support ran.


    Ich selbst habe den Fehler noch nie gesehen, er wurde mir als lang anhaltendes Flackern der LEDs beschrieben. Scheint hier nicht der Fall zu sein.


    CU
    Oliver

    Falls beim Einschalten des PCs die LEDs des MAX S8 sehr lange flackern, ist vermutlich der PCIe Slot nicht voll beschaltet.


    Abhilfe:
    Jumper auf der MAX S8 stecken (steckt serienmäßig drauf, aber "daneben", d.h. offen).


    CU
    Oliver

    Richtig, das funktioniert. Denn der Access Point kann alles mitlesen, was über sein WLAN geht. Natürlich kann der PC die Kommunikation in diesem Fall auch einfach auf dem Ethernet-Interface sniffen. Geht ja alles durch den PC...


    Muß alles "nur" korrekt konfiguriert werden... :D


    CU
    Oliver


    Bitte wer? Ich dachte mit Ettercap * ARP-Spoofing kann ich mir die Pakete geiern?


    Hängt davon ab, ob es dem Sniffer-PC tatsächlich gelingt, "Man in the middle" zu werden. Imho ist das in dieser Konstellation keineswegs sicher. Hängt von den beteilgten Systemen ab (Timing und Dummheit der Programmierer). Beide Kommunikationspartner können erkennen, dass etwas faul ist...


    CU
    Oliver

    Wie schon geschrieben wurde, wirst Du an einem Switch-Port den Traffic nicht sniffen können - es sei denn, man kann den Port als Mirror-Port konfigurieren oder man kann Address-Learning abschalten. Beides können die Billigswitches i.d.R. nicht.


    Hast Du evtl. noch irgendwo einen alten Ethernet-Hub herumliegen? Diesen könnte man zwischen TV und Switch schalten, und an einem Hub-Port den Traffic sniffen.


    CU
    Oliver.

    Quote


    Hmm, der Fehler stammt von einer Kernel-Build Variante (i386/desktop), die CONFIG_OF und Konsorten gerade nicht aktiviert hatte.
    ...
    Offenbar ist dies bei x86_64 builds der Fall, da ist CONFIG_OF auch nicht gesetzt.


    Kann nicht sein. Wenn CONFIG_OF deaktiviert wäre, würde der fragliche Treiber nicht gebaut:

    Code
    1. ...
    2. config VIDEO_XILINX
    3. tristate "Xilinx Video IP (EXPERIMENTAL)"
    4. depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
    5. ...


    CONFIG_OF stammt aus .config des Kernels. Bei mir (Debian) ist dies immer aktiviert - sowohl bei 64 Bit als auch 32 Bit. Macht jedoch nur bei 32 Bit Probleme.


    CU
    Oliver

    Hatte ich auch schon einmal auf einem 32-Bit System. Aus irgendeinem Grund scheint es da einige Funktionen nicht zu geben. Da ich keine Lust hatte, mich durch Kernel und Upstream-Treiber zu graben, habe ich "CONFIG_OF" in v4l/.config und v4l/.myconfig deaktiviert...


    Eine sauberere Methode wäre, alle Treiber, die von "OF" abhängen, per "make menuconfig" zu deaktivieren...


    CU
    Oliver

    Danke, UFO, für den Patch. Ich bin allerdings ab morgen bis 11. Juli in Urlaub und komme erst danach wieder dazu, am VDR zu arbeiten.


    Dann wünsche ich schon mal einen schönen Urlaub!


    Quote


    Ein Grund, 64-Bit zu meiden, wenn man es nicht unbedingt braucht ;-).


    Ist leider nicht ganz so einfach. Wie ich feststellen musste, läuft das 32-Bit dvbhddevice nicht mit dem 64-Bit Treiber. Da gibt's Probleme - vermutlich infolge der unterschiedlichen Größe von "Ptr" und "long". -> Andere Baustelle.


    CU
    Oliver

    Ob new oder malloc, ist sch...egal. Wenn ich zu wählen habe, würde ich - in diesem Fall - malloc nehmen, denn Sort() hat nicht viel mit C++ zu tun. Da brauche ich nicht ausgerechnet für die Allokation C++ zu nehmen. (Außerdem fange ich bei new immer an zu überlegen, ob da nicht irgendwelche Konstruktoren mit ausgeführt werden...)


    Allen, die Lust haben, sich mit solchen Nichtigkeiten aufzuhalten, empfehle ich, ihre Energie in die Fehlersuche zu investieren. Da kommt man gleich auf ganz andere Gedanken. :wow


    Es sieht nämlich nicht so aus, als ob hiermit der eigentliche Fehler behoben wäre. Es war nur ein Nebenprodukt der Fehlersuche.


    Bei der riesigen Menge an Allokationen/Deallokationen, die in VDR stattfinden, muß man mit einer Fragmentierung des Heaps rechnen. Ein Anwachsen des Speicherbedarfs bedeutet also erst mal nicht notwendigerweise, dass es ein Speicherleck gibt. Es sieht allerdings verdächtig danach aus.


    valgrind findet jedoch nichts. Dies bedeutet, dass valgrind es entweder übersieht, oder die Blöcke nicht wirklich verloren sind und in irgendwelchen Datenstrukturen/Listen herumgammeln.


    CU
    Oliver

    Bin nicht sicher, ob folgendes die oder eine Ursache unseres Problems ist, ein Bug ist es auf jeden Fall:


    cListBase::Sort() legt ein Array von Pointern auf den Stack, was bei großen Listen problematisch ist:

    Code
    1. int n = Count();
    2. cListObject *a[n];


    Auf 64-Bit Systemen sind Pointer 8 Byte statt 4 Byte groß, daher ist das Array gleich doppelt so groß. Hier hat es gekracht, als ich versucht habe, alle Sendungen auf allen Kanälen anzuzeigen...


    Der angehängte Patch alloziert das Array auf dem Heap.


    CU
    Oliver

    Danke, der Aufwand hält sich ja zum Glück in Grenzen.


    Mit den Änderungen 2. + 3. scheint der Speicherbedarf nach einiger Zeit nicht mehr weiter anzuwachsen. Ist allerdings nicht wirklich überraschend, da keine Daten mehr dazukommen.


    Ich werde das ganze jetzt noch einige Zeit laufen lassen und dann in den nächsten Tagen die Änderungen einzeln zurücknehmen...


    CU
    Oliver

    Habe nun valgrind mit der HDFF-Installation auf einer schnellen Maschine eine Zeit lang laufen lassen:

    Code
    1. ==13718== LEAK SUMMARY:
    2. ==13718== definitely lost: 6,784 bytes in 27 blocks
    3. ==13718== indirectly lost: 2,151 bytes in 101 blocks
    4. ==13718== possibly lost: 0 bytes in 0 blocks
    5. ==13718== still reachable: 434,621 bytes in 3,150 blocks
    6. ==13718== suppressed: 0 bytes in 0 blocks


    Die gefunden Leaks hängen alle irgendwie mit fontconfig-Gedöns zusammen:


    Das ganze führt jedoch zu nichts, denn das sind lächerliche ~9 KByte - viel zu wenig!


    Das eigentliche Problem muß imho irgendwo in den "still reachable" Blocks stecken. Nicht alles, was reachable ist, muß auch korrekt sein.


    kls
    Wo könnte man am besten ansetzen, um folgende Komponenten vollständig außer Kraft zu setzen:
    1. OSD-Generierung abschalten (insbesondere keinerlei Fontverarbeitung mehr)
    2. Channel-und CA-Descriptor Update
    3. EPG-Verarbeitung


    Ich würde gerne versuchen, das Problem auf einen Themenkomplex einzukreisen.


    Btw, das ganze ist insofern schwierig, da die HD-FF in einem Produltivsystem steckt. Ein längerer Betrieb mit valgrind kommt selbst auf der schnellen Maschine nicht in Frage, denn die Reaktionszeit des Systems ist völlig inakzeptabel...


    CU
    Oliver

    Zum Vergleich wollte ich auf dem 64-Bit System einen - mit identischer Konfiguration gebauten - 32-Bit VDR laufen lassen.


    Leider klappt dies nicht. Nachdem ich die Klippen mit pkgconfig + fontconfig umschifft hatte (64-Bit und 32-Bit Version schließen sich gegenseitig aus - immer nur Ärger mit diesen Sch...tools), ließ sich endlich alles übersetzen und starten. Aber leider kann das 32-Bit dvbhddevice offenbar nicht auf den 64-Bit DVB-Treiber zugreifen...


    Also alles zurück auf 64-Bit.


    Btw, als ich den 64-Bit VDR abgebrochen hatte, war der Speicherbedarf bei ~460 MB.
    Kurz nach dem Neustart der 64-Bit Version ist er nun bei ~280 MB.


    CU
    Oliver