mit msi=0 bekomme ich auch keine ausgabe.
Was steht im Log? Sind die I2C-Fehler damit weg? Dann wäre man einen Schritt weiter.
Keine Ausgabe kann einfach bedeuten, dass fmode falsch eingestellt ist.
Wie und an was ist die Karte angeschlossen?
CU
Oliver
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
Interessant. Hier bekommt man VDSL nur als IP-Anschluss. Wer POTS/ISDN behalten will, muss sich mit ADSL2 begnügen.
CU
Oliver
Bei VDSL gibt es kein Annex J, und afaik sind VDSL-Anschlüsse immer IP-Anschlüsse.
Es kann eigentlich nur um Vectoring gehen, was die FB 7570 nicht kann.
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... 
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:
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
Bitte neu auschecken. Müßte jetzt funktionieren.
CU
Oliver
Offenbar habe ich vergessen, den lnbh25-Treiber zu integrieren. Dieser wird für die neueste Generation benötigt. Werde ich reparieren. Sorry.
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. 
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:
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
Is the card connected correctly to the SCR line? You must use port #1 for fmode=3. The ports are numbered from top to bottom. See http://www.digital-devices.eu/…547c5ee6bde15_720x600.png
CU
Oliver
Habe nun valgrind mit der HDFF-Installation auf einer schnellen Maschine eine Zeit lang laufen lassen:
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
Ich würde einzelne - scheinbar verlorene - Blocks bei der Initialisierung erst mal außer Acht lassen. Das kann nicht das eigentliche Problem sein.
Alle Tools, mit denen ich experimentiert hatte, hatten Probleme, sobald fork() bzw. Laden von Shared Libraries ins Spiel kamen...
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
