sh4 firmware Problem

[schufti]

Hi,
wie schon vor einiger Zeit (in einem leider unpassendem Thread) von mir geposted, habe ich Probleme mit NeutrinoHD auf sh4. Selbst ohne div. "Plugins" kommt es auf freien HD Sendern immer wieder zu Abstürzen des Videodecoders. Auffällig schnell/oft auf "Das Erste HD"

Code: Alles auswählen

[  154.168000] ***** Fatal-H264 Codec Int: Buffer_Generic_c::IncrementReferenceCount - Attempt to act on a buffer that has a reference count of zero.
[  154.168000] Stack: (0x8520de6c to 0x8520e000)
[  154.168000] de60:                            80b4f4e6 8520de7c c15d2e90 000000c8 c15b01a4
[  154.168000] de80: 8520de84 8520de9c c15a6f90 8520dea4 8520dea0 ffffffff 8453c500 c15d3420
[  154.168000] dea0: 000001bc c1580682 8520debc 00000000 8520dea0 00000060 c1bc5000 00000000
[  154.168000] dec0: 00000000 00000000 00000000 00000000 00000000 001b3000 00000000 0000000a
[  154.168000] dee0: c1581a48 8520df00 0000ea7c 00000000 c1bc8a50 c1bc69bc 00000001 c1bc5000
[  154.168000] df00: c15a7314 c1584810 8520df20 00000000 c1bc8a50 0000002c 00003a84 c1bc5000
[  154.168000] df20: 8520df00 8520df00 00010138 00000000 00000005 00010138 00000000 00000005
[  154.168000] df40: c1584946 8520df60 00000000 00000000 8519f820 c15b0d0c 00000000 8519f820
[  154.168000] df60: c15b0d1c 8520df68 808278d6 8520df74 85109ab8 00000000 00000000 8520df7c
[  154.168000] df80: 8520df7c 808039ec 8520df9c 00000000 00000000 00000000 00000000 00000000
[  154.168000] dfa0: 00000000 00000000 00000000 00000000 00000000 85109ab8 8082787c 00000000
[  154.168000] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  154.168000] dfe0: 8520dfa4 808039e4 00000000 40008000 00000000 00000000 00000000 00000000
[  154.168000]
[  154.168000] Call trace:
[  154.168000]  [<80b4f4e6>] dump_stack+0xe/0x1c
[  154.168000]  [<c15b01a4>] report+0x84/0x100 [player2]
[  154.168000]  [<c15a6f90>] _ZN16Buffer_Generic_c23IncrementReferenceCountEj+0x28/0xc0 [player2]
[  154.168000]  [<c1580682>] _ZN15Codec_MmeBase_c28TranslateReferenceFrameListsEb+0x17a/0x1fc [player2]
[  154.168000]  [<c1581a48>] _ZN16Codec_MmeVideo_c5InputEP8Buffer_c+0x31c/0x494 [player2]
[  154.168000]  [<c15a7314>] _ZN16Buffer_Generic_c12ShrinkBufferEj+0x44/0x68 [player2]
[  154.168000]  [<c1584810>] _ZN20Codec_MmeVideoH264_c19IntermediateProcessEv+0x220/0x34c [player2]
[  154.172000]  [<c1584946>] Codec_MmeVideoH264_IntermediateProcess+0xa/0x24 [player2]
[  154.172000]  [<c15b0d0c>] OSDEV_CreateThreadHelper+0x0/0x28 [player2]
[  154.172000]  [<c15b0d1c>] OSDEV_CreateThreadHelper+0x10/0x28 [player2]
[  154.172000]  [<808278d6>] kthread+0x5a/0x78
[  154.172000]  [<808039ec>] kernel_thread_helper+0x8/0x14
[  154.172000]  [<8082787c>] kthread+0x0/0x78
[  154.172000]  [<808039e4>] kernel_thread_helper+0x0/0x14
[  154.172000]

auf Grund der mangelnden Reaktionen habe ich mich dann mal hingesetzt und versucht, zu ergründen, warum das Problem in anderen Images nicht auftritt. Dabei hat sich heraus gestellt, dass das (fast ausschließlich) von der geladenen video.elf abhängig ist. Bisher habe ich zwei verschiedene Versionen gefunden, die sich speziell in der intern ausgewiesenen H264 Version unterscheiden. Und gerade mit der "älteren" läuft es (fast) problemlos. Ob da jetzt noch eine zusätzliche Abhängigkeit mit den in den jew. Images zuarbeitenden Linuxtreibern besteht konnte ich nicht ermitteln.

Ich denke, wenn der Treiber den Fehler abfangen und den videodecoder neu starten könnte, wäre das Problem ev. lösbar (falls schnell genug) soetwas ähnliches waren dia avia watchdogs ja doch auch, oder?

Jedenfalls fände ich es traurig, wenn hier auf der als so "open source" hochgejubelten sh4 Plattform wieder der gleiche fw Sch... wie schon auf der dBox stattfindet, wo verschiedene mystische fw Versionen im Netz kursieren, keine läuft 100% und niemend weiß warum bzw. kann etwas dagegen tun.

[seife]

Also ich habe diese Firmwares im Einsatz:

Code: Alles auswählen

spark:/boot # ls -l *elf
-rwxrwxrwx    1 root     root       2720860 Jan 22 17:50 audio.elf
-rwxrwxrwx    1 root     root       1655072 Jan 22 17:50 video.elf
spark:/boot # md5sum *elf
584b1432f8a796f370ac7d108cb74529  audio.elf
073cca42ac28293b50e4654b13b6ce46  video.elf

Und da tritt dieses Problem eigentlich nur auf, wenn dem Videodecoder bei laufendem Playback die Daten ausgehen. Deswegen ist auch der Hack im zapit code, der den Videodecoder anhält, wenn das Frontend den Lock verliert. Da trat das nämlich reproduzierbar auf: HD Sender, Antennenkabel raus -> bumm.

Ich habe mir auch schon die Treiber angeschaut aber die sind nicht von der Art, dass man sich das ohne bleibende Schäden zu Gemüt führen will

Wenn du einen Patch dazu hast, wäre ich darüber natürlich dankbar.

[schufti]

ja, das ist die Version mit der ich auch am wenigsten Probleme habe. Da ist die intern ausgewiesene H264 Version 7.0.3

mit der hier

Code: Alles auswählen

197ffa20113c1e57a2e1697f69e4aa99 audio.elf
639146e2a6255ba244bdf49a20e777d6 video.elf

gibt es die besagten Fehler regelmäßig, die interne H264 Version ist 8.1.3

Wäre interessant, warum davon - zumindest bei mir - Das Erste HD am schlimmsten betroffen ist.

SW-Entwicklung auf (Embedde)Linux ist mir zwar nicht fremd aber um dafür einen Patch hervorzuzaubern habe ich mich noch zu wenig mit Multimedia-HW und Neutrino beschäftigt.

[dietmarw]

dann hab ich wohl nur die falschen versionen..

einige versionen habe ich ja nun schon gefunden, aber eure genannten nicht..

(letzte vier ziffern der md5sum)

audio.elf
1708
aa99
d443

video.elf
77d6
8556
e582
ce46 edit: jetzt enthalten

[OSi]

dann hab ich wohl nur die falschen versionen..

einige versionen habe ich ja nun schon gefunden, aber eure genannten nicht..

Geht mir leider nicht anders, ich frage mal ganz vorsichtig nach einer Quelle

[seife]

Ich habe meine aus pinky's image extrahiert.

[doc]

Um noch etwas Verwirrung zu stiften ...
Zusätzlich zu den bekannten Versionen

Code: Alles auswählen

197ffa20113c1e57a2e1697f69e4aa99  /boot/audio.elf 
639146e2a6255ba244bdf49a20e777d6  /boot/video.elf

habe ich noch folgende Versionen gefunden.

Code: Alles auswählen

70e1e33f10ae002c17b34fd1dfa645ed  ../Downloads/boot/audio.elf
8dfc37893f8c90aaf62d7138c66248a8  ../Downloads/boot/video_7100.elf 
c284a7f3610ac6e29b154bf0928d0d54  ../Downloads/boot/video_7109.elf

Vieleicht könnte man etwas Ordnung in die verschiedensten Versionen bringen?
Gibt es noch weitere Varianten?

[OlliT]

Um noch etwas Verwirrung zu stiften ...
Zusätzlich zu den bekannten Versionen

Code: Alles auswählen

197ffa20113c1e57a2e1697f69e4aa99  /boot/audio.elf 
639146e2a6255ba244bdf49a20e777d6  /boot/video.elf

habe ich noch folgende Versionen gefunden.

Code: Alles auswählen

70e1e33f10ae002c17b34fd1dfa645ed  ../Downloads/boot/audio.elf
8dfc37893f8c90aaf62d7138c66248a8  ../Downloads/boot/video_7100.elf 
c284a7f3610ac6e29b154bf0928d0d54  ../Downloads/boot/video_7109.elf

Vieleicht könnte man etwas Ordnung in die verschiedensten Versionen bringen?
Gibt es noch weitere Varianten?

die 7100er (Sti 7100/7101) und 7109er (Sti 7109) elf's sind ja für die Spark-Boxen nicht relevant. Die gehören zu den Boxen der alten Generation. Für den Spark (Sti 7111) gehen die elf's des 7111 und 7105er (quasi die Twin-Version des 7111).

[Grabber66]

Und da tritt dieses Problem eigentlich nur auf, wenn dem Videodecoder bei laufendem Playback die Daten ausgehen. Deswegen ist auch der Hack im zapit code, der den Videodecoder anhält, wenn das Frontend den Lock verliert. Da trat das nämlich reproduzierbar auf: HD Sender, Antennenkabel raus -> bumm.

hi, hast du evtl. für mich nen Link zu dem "Hack" ? Ich würde mir das gerne mal anschauen. thx

[seife]

zapit.cpp, ist ein dicker kommentar drüber.

[AudioSlyer]

https://gitorious.org/neutrino-hd/neutr ... c36e5ebe71

[Grabber66]

Danke für die Infos.

Bekomme ich eigentlich irgentwo ne Übersicht welche Versionen (7011,7109 etc.) zu welcher md5sum gehören.

[doc]

Bis jetzt nicht.
Das war aber meine Absicht das man das hier mal zusammen trägt und dann z.B. einfach ne spark_firmeware.readme mit im BS/Wiki hinterlegt.
So lange keiner einen guten Draht zu Spark selber hat wird das Try&Error bleiben.

[schufti]

bezüglich dem Würgaround für "lost lock":

ist das eigentlich wirklich notwendig?
sowohl TDT (hier ist der "retune" deaktiviert) als auch mohousch haben nichts dergleichen und man liest nichts über Probleme. Kann es sein, dass da damals eher eine schlechte video.elf das Problem war?

[seife]

stört es? Abstürzende Treiber finde ich unschön, egal wer schuld ist.

[schufti]

naja, einer Aufnahme mit 5min Loch kann ich noch etwas abgewinnen, eine Aufnahme die nach 5min nur mehr als Standbild bringt ist ....

wollte ja nur wissen, ob das damals mit mehreren video.elf verifiziert wurde oder bloß wegen einer "problematischen" FW eine doch eher radikale Lösung überhastet "Abhilfe" schuf.

Sicher wäre es sauberer den Tunertreiber so zu ändern, dass er von selbst wieder sein Lock findet. Oder noch besser, den Decoder fault-tolerant. Das wird aber vermutlich zu Lebzeiten der jetzigen SH4 Boxen nicht geschehen... also wird wohl die zweitbeste Lösung (ein retune ?) platzgreifen müssen.

Zu dBox2 Zeiten gabs solche Probleme ja auch zu Hauf und mit den div. Watchdogs auch kreative Lösungen. Muß doch hier auch möglich sein, das eleganter zu lösen...

[seife]

Die Aufnahme wird von diesem Workaround überhaupt nicht beeinflusst. Es wird nur der Videodecoder angehalten.
Ausserdem findet der Tunertreiber seinen Lock typischerweise schon selbsttätig wieder, mir ist also unklar, worüber du hier überhaupt redest...

[schufti]

naja, nach längeren (minutenlagen) Schlechtwetterphasen (Gewitter) bleibt einfach Standbild am TV. Mit einmal Zappen läufts dann wieder. Ich dachte, dass das durch den Fix hervorgerufen wir, da ich da bisher nie anwesend war und daher auch kein Log mitlief ...

Dann ist das vermutlich ein reines "Tuner" Problem (was auch die defekte Aufnahme erklären würde), das sich aber auch trefflich an dieser Stelle fixen ließe...
daher vermutlich auch der nachfolgende, mit "if 0" rausgenommene Teil wo je nach Signalqualität ein retune gemacht wird ???

scheinbar haben viele Sparkboxen jetzt halt typischer Weise einen untypischen Tuner

[seife]

Dieser #if 0'te code ist orginal von mixvt und war nie aktiv. Die Signalstärke die der Tuner anzeigt ist ja auch wirklich kein Indiz dafür, ob das Signal nun gut ist oder nicht

Selbst wenn neu tunen an der stelle implementiert wird (nach minuten ohne Lock kann es schon sein, dass der Tunertreiber aufgegeben hat, das habe ich mir noch nie angeschaut) setzt dir das die demultiplexer etc. nicht neu auf. Und wenn mehrere Minuten keine Daten kamen, hat der record-code sicher auch schon aufgegeben.

Wenn du zuverlässig aufnehmen willst, nimm einen VDR

[schufti]

aber wenn im unlocked Zustand nach dem Stoppen des Decoders ein Zähler startet, der z.B. alle 10000 ein retune macht, dann müßte sich der locked Zustand wieder irgendwann ergeben und den Decoder wieder starten, oder?