[Prototyp] RPI Ausgabeplugin

Quote from Argus

mit gcc 4.6 läufts, mit gcc 4.8 nicht. Compilieren tun beide, aber das Compilat vom gcc 4.8 ist auch 640k groß, das vom gcc 4.6 nur 517k (beides mit gleichen Einstellungen compiliert)

Vielen Dank fürs Feedback - hmm... langsam aber sicher verstehe ich die Welt nicht mehr.

Ratlos,
Thomas

Quote from Argus

wenn der gcc im Arm Bereich vielleicht noch weitere Bugs beinhaltet,
was spricht eigentlich dagegen, derzeit die Empfehlung für ein Downgrade auf gcc 4.6 auszusprechen.

Na ja, die Wahrscheinlichkeit dass es sich um einen Fehler im Compiler handelt, ist wohl recht klein. Hier ist auch die Rede davon, dass 4.7 und 4.8 schnellere Kompilate erzeugen - und da diese scheinbar auch grösser sind, wird wohl einfach anders optimiert. Ich vermute deshalb das Problem bei der Reihenfolge, wie die Threads im Plugin gestartet werden, und dass sich da vielleicht ein Deadlock ergibt, weil neuere Compiler anders optimieren. Das ist momentan die logischste Erklärung die ich mir machen kann.

Gruss
Thomas

Quote from clausmuus

bist Du denn schon dazu gekommen, das ganze auch Fehler beim Speicherzugriff zu untersuchen, so wie ich das vor ein paar Tagen vorgeschlagen hatte, oder ist das aktuell diskutierte Problem noch ein anderes?

Nein, das versuche ich heute Abend. Aber es gab auch ein Problem, bei dem im Log die Meldungen "rpihddevice: failed to pass buffer to video decoder!" auftauchen - dieser Fehler sollte mit dem Patch eigentlich behoben sein. (OMX-Events gehen verloren, dadurch wird die Video-Pipe nicht komplett aufgesetzt und der Decoder "verstopft") Meine Hoffnung war halt, dass das Compilerproblem auch damit zusammenhängt - ist aber scheinbar nicht so.

Gruss
Thomas

Also, mit DUMA (Nachfolger von efence) startet nicht mal mehr plain vdr ohne abzustürzen und valgrind meint bei der Installation:

checking for a supported CPU... no (armv6j)
configure: error: Unsupported host architecture. Sorry

So wirklich Spass machen tut das so nicht...

Gruss
Thomas

Hi Guido

Quote from Guido17

ich habe mir gerade einmal den Source von cOmx angesehen, ich denke, da fehlt auch ein Mutex und zwar für "m_portEvents".
diese Queue wird in Action verarbeitet, aber der push erfolgt vielleicht in einem anderen Thread.

Hast du dir die Sourcen aus dem GIT angeschaut, oder hast du diesen Patch schon appliziert?

Mit dem Patch sind die direkten Zugriffe auf die Queue (IMHO) alle geschützt, geschrieben werden die Events grundsätzlich nur via Callbacks aus dem OMX-Kontext.

Gruss
Thomas

Quote from Macavity

Vielleicht hilft Dir das: http://www.raspberrypi.org/forums/viewtopic.php?f=66&t=7689

oder das: http://www.raspberrypi.org/forums/viewtopic.php?f=33&t=50675

Danke für die Links! Bei Valgrind komme ich mir der Anleitung bei "./configure" bis zu:

checking the GLIBC_VERSION version... unsupported version 2.15
configure: error: Valgrind requires glibc version 2.2 - 2.14

Den Downgrade von glibc auf 2.14 mochte mein System gar nicht... zum Glück mounte ich das Filesystem über NFS, da war das schnell wieder geflickt.

Bleibt noch efence als letzter Versuch.

Gruss
Thomas

Quote from GTRDRIVER

Bisher sind die von dir beschriebenen Log-Meldungen nicht mehr aufgetreten.

Das ist schon mal gut - danke fürs Testen!

Quote from GTRDRIVER

Was ich immer noch regelmäßig beobachte: "Butter stall"

Wie regelmässig? Sehe ich bei mir auch zwischendurch, vielleicht jedes zwanzigste Mal, wenn ein neuer Stream startet (Kanalwechsel oder Starten einer Aufnahme).

Quote from GTRDRIVER

Zudem hängt sich der VDR beim beenden einer Wiedergabe alle 2-3 Tage komplett auf so dass der Watchdog nach der eingestellten zeit zuschlägt.
Es kommen aber keine Meldungen etc...

Du hast nicht per Zufall das Log, was vorher passiert ist? Interessant zu wissen wäre auch, ob die CPU-Last dabei hoch geht, weil z.B. ein Thread in einer Endlosschleife dreht.

Gruss
Thomas

Zum Thema gcc: Da die Probleme scheinbar ab Version 4.7 auftreten, habe ich mir mal dessen Release Notes angesehen:

Quote

On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A, ARMv7-R, or ARMv7-M, the new option -munaligned-access is active by default, which for some sources generates code that accesses memory on unaligned addresses. This requires the kernel of those systems to enable such accesses (controlled by CP15 register c1, refer to ARM documentation). Alternatively, or for compatibility with kernels where unaligned accesses are not supported, all code has to be compiled with -mno-unaligned-access. Upstream Linux kernel releases have automatically and unconditionally supported unaligned accesses as emitted by GCC due to this option being active since version 2.6.28.

Könnte das ein Problem sein? Wenn ja, könnte jemand mit gcc-4.7 den Test aufs Exempel machen, und das Plugin mit dem Flag "-mno-unaligned-access" kompilieren? Ich denke mal, das müsste dann so aussehen:

diff --git a/Makefile b/Makefile
index 3012449..7881cee 100644
--- a/Makefile
+++ b/Makefile
@@ -49,7 +49,7 @@ SOFILE = libvdr-$(PLUGIN).so
 
 DEFINES += -DPLUGIN_NAME_I18N='"$(PLUGIN)"'
 DEFINES += -DHAVE_LIBOPENMAX=2 -DOMX -DOMX_SKIP64BIT -DUSE_EXTERNAL_OMX -DHAVE_LIBBCM_HOST -DUSE_EXTERNAL_LIBBCM_HOST -DUSE_VCHIQ_ARM
-DEFINES += -Wno-write-strings -fpermissive
+DEFINES += -Wno-write-strings -fpermissive -mno-unaligned-access
 
 CXXFLAGS += -D__STDC_CONSTANT_MACROS

Gruss
Thomas