Mount-Problem rev2741

[BPanther]

aufgewacht sind meine Boxen aus Deep StandBy bis jetzt immer. Heute Morgen hab ich noch per Timer das Formel1 Qualifying aufgenommen, danach hat sich die Box wieder schlafen gelegt.
(Ich war ja auch noch süss am pennen )

Na immerhin, da das aber bei einigen nicht funktioniert hat, habe ich halt nochmal genauer nachgeschaut und dabei ist mir das aufgefallen.

Mir ist wohl ausgefallen, das beim ausschalten eine ../enigma2/timer.xml oder so ä. nicht gefunden wird ?? Muss ich noch mal drauf achten.

Vollkommen normal. Es wird nach beiden Dateien gesucht, sowohl der von E2 als auch der von Neutrino - wenn die von E2 nicht gefunden wird. Beim aktivierten E2-Patch der letztens hinzugefügt wurde, kommt keine der beiden Meldungen, da wird nämlich keine der beiden Dateien angesprochen/abgefragt. Eben das führt dann zum Problem bei dem die Timer-Zeit nicht gefunden und somit nicht programmiert wird.

In den vergangenen Monaten ist ja auch viel in Bezug auf STM24 an den externen Modulen rum gepatcht worden. Ist da versehentlich eine Beule eingebaut worden? Der Tunertreiber ist ja komplett
getrennt, die anderen Sourcen werden ja gemeinsam benutzt, mit if... Verzweigungen was ich so gesehen habe.

Macht das nicht Sinn die Modul Sourcen alle zu trennen?

Hier verstehe ich nicht ganz genau, was Du meinst. Es werden doch alle zusätzlichen Treiber/Programme separat über "if" gebaut, so auch die Tunertreiber.

[DboxOldie]

Hier verstehe ich nicht ganz genau, was Du meinst. Es werden doch alle zusätzlichen Treiber/Programme separat über "if" gebaut, so auch die Tunertreiber.

Ich meine das: Der Tunertreiber wird in einem seperaten Ordner mit "_dvbapi5" Zusatz für STM24 kompiliert.
Bei anderen Modulen innerhalb der c-Datei verzweigt z.Bsp. so: #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,17).

Aber die "mount" Geschichte betrifft ja beide Versionen , das sollte dann nicht das Problem sein.

Ich war es von der D-Box so gewohnt, das die externen Modul-Bäume für die Kernel komplett getrennt waren.

[BPanther]

Achso, das. Das liegt eher daran, daß der Treiber komplett neu erstellt wurde und man da nicht einfach nur mit ein paar "if's" zwischen den stm-Versionen unterscheiden kann.

[Helli]

@DboxOldie
Die Aufnahmen funktionen, bisher keine Probleme.

Danke für deine Hilfe.

Helli

[DboxOldie]

@Helli:
freut mich wenn das soweit klappt, ist zwar keine endgültige Lösung aber bei SD Aufnahmen ist die Wahrscheinlichkeit der "mount Verluste" wesentlich geringer.
Allerdings nicht komplett ausgeschlossen wegen dem camRouting, leider.

[BPanther]

Ich habe jetzt einfach mal hotplug deaktiviert (direkt in /proc mit echo "" > /proc/sys/kernel/hotplug), noch scheint es zu funktionieren. Teste aber derzeit noch was anderes deswegen.

[DboxOldie]

Das könnte ich auch mal probieren, beim Start geht er ja dann noch

[Helli]

ich bin mit der Hilfslösung vollkommen zufrieden; bisher keinen Aussetzer.
Wenn es eine neue ImageVersion gibt, reicht es dann wieder aus die beiden Dateien in das Verzeichnis zu kopieren?

Gruß,
Helli

[BPanther]

Ja, derzeit kein Problem (getestet bis rev2901), da sie kompatibel sind, so wie früher die stmdvb/pti von tdt.

[Helli]

super, danke für die Hilfe

Helli

[BPanther]

Kurze Status-Info zum Problem. Das Problem selbst liegt, wie bereits festgestellt, in den beiden Dateien stmdvb.ko und pti.ko. Inzwischen konnte es aber noch genauer bestimmt werden.

Aber zunächst meinen besten Dank an DboxOldie für seine hartnäckigen Tests bei dem Problem, dadurch war es möglich, das Problem genauer eingrenzen zu können.


Zunächst ist es beim PTI das camRouting, welches ermöglicht, daß CI-Module bei der UFS910 verwendet werden können, da der Stream dann etwas anders gehandhabt wird. Ist es aktiviert, kommt es bereits zu den Mountverlusten. Im Zusammenspiel mit den player2_179-Änderungen >rev2037 passiert dies aber auch ohne camRouting, braucht dann nur zum Teil etwas länger. Ein Diff, welches die Unterschiede des p179 ab rev2037 zeigt, ist inzwischen erstellt und wird nun nach und nach getestet bzw. ab welcher Änderung das Problem auftritt um es besser eingrenzen und beheben zu können. Das camRouting-Problem der PTI wird dann erst im Anschluß daran in Angriff genommen, sofern es nicht eh entfernt werden kann, denn die letzten Versionen zeigen, daß CI-Module auch ohne durchaus funktionieren können (getestet mit Diablo WiFi).

Um es nochmal zu verdeutlichen: der p179_rev2037 + pti ohne camRouting sind STABIL ohne jegliche Mountverluste. Wer es selbst testen will, kann dies gerne tun. Derzeit liegt auf dem Server die rev2932 als "<DONT USE THIS> (p179)" im Online-Update zu sehen. Diese installieren und die pti.ko, ebenfalls in Experimentell zu finden, nach /var/lib-misc schieben und die Box neu starten. Es funktionieren damit keine CI-Module, jedoch gibt es keine Mountverluste.

[BPanther]

Alles weist darauf hin, daß in dem Moment, wenn das CI Modul aktiviert wird (via pti und/oder stmdvb) der Bug auftritt. Wird es intern abgeschaltet gibt es keinerlei Mountverluste. Es geht hierbei um die internen Funktionen die den Fehler auslösen, d.h. selbst wenn das Modul steckt und nicht angesprochen wird bleiben die Mounts stabil. Werden die Funktionen intern aktiviert ist es egal ob ein Modul steckt oder nicht, es kommt zum Mountverlust.

Dann noch ein anderer Hinweis zum highSR in diesem Zusammenhang. Auch der highSR ist von den CI Funktionen abhängig wie es scheint. Zudem war highSR schon lange nicht mehr im GIT real aktiv, d.h. egal ob er aktiviert wurde oder nicht, er war immer aus. Die stmdvb auf dem Server in Experimentell hat inzwischen 5 mögliche Werte bei highSR (muß dann von Hand in die rcS geschrieben werden).

highSR=0 oder fehlt -> kein CI - so wie im GIT -> scheint stabil zu sein (~15GB via FTP->PC waren OK)
highSR=1 -> CI "halb aktiv" (wird angesprochen, funktioniert aber nicht) -> Mountverluste
highSR=2 -> CI "halb aktiv" (wird angesprochen, funktioniert aber nicht) -> Mountverluste
highSR=3 -> CI "halb aktiv" (wird angesprochen, funktioniert aber nicht) -> Mountverluste
highSR=4 -> CI "halb aktiv" (wird angesprochen, funktioniert aber nicht) -> Mountverluste

In der letzten experimentellen Version ist das camRouting=1 bei der pti intern, d.h. das CI Modul würde dann bei highSR=1..4 normal funktionieren, nur bei camRouting=0 als Parameter bei der pti.ko wäre es "halb aktiv".

Da es ja User gab, die highSR brauchten, sollten diese mal die erweiterte highSR-Option versuchen, aber wie gesagt, es wird dann Probleme mit den Mounts im laufe der Zeit geben. Wahrscheinlich wurde das deswegen mal im GIT abgeschaltet...