niemand0815

lass dir zeit. wenn das klappt und wir quasi einen universellen watchdog für den avia+enx bekommen ist es das warten wert *g*

ich hatte 2 mal den fall bisher. aber nicht reproduzierbar. die obigen massnahmen waren ja eher mehr als beispiele gedacht. was ist denn normalerweise das was man manuell macht? macht spts an/aus was anderes als rezap? (ich meine natürlich ausser spts) der vorteil bei spts an/aus wäre imho sonst nur das man eben keinen anderen kanal "belästigt" und somit vielleicht die störung etwas subjektiv angenehmer ist. wichtig ist das der watchdog nicht komlett die kiste lahmlegt, also sollten wir nicht zu agressiv rezappen. ich denke: 5 sekunden enx-resets, wenn erfolglos dann rezap und 10 sekunden warten, dann wieder mit enx-resets starten. usw. aber ich denke mit den zeitparametern muss man experimentieren.

na das ist doch schon. @newcode: wie wäre es eine "massnahmeneskalation" mit einzubauen? erstmassnahme: enx reset wenn das für x mal nicht erfolgreich war: spts mode toggeln wenn das nicht erfolgreich war echter rezap wenn das nicht erfolgreich war camd reset (das dürften doch alle gängigen massnahmen in der reihenfolge ihrer auswirkungen auf das laufende bild von wenig bis hoch sein, oder?) zumindest so ähnlich wäre das doch wirklich eine netter "nächster level" für den watchdog :-)

ist während dem tonda/bildweg effekt eigentlich das script angesprungen? sprich: wurden die interrupts hochgezählt oder nicht? denn wenn das script angesprungen ist wäre es vielleicht eine idee nach 10 aufeinanderfolgenden resets ohne erfolg automatisch den spts mode einmal zu "toggeln". oder eben einen echten rezap zu machen. ich vermute aber mal das während dieses effektes die interrupts munter weiterlaufen und somit das script nicht anspringt.

@newcode: es könnte ein indirekter effekt sein. der enx liefert ja daten für andere prozesse. wenn nun etwas anderes daten schlecht "abnimmt" oder der bus "stau" hat könnte ich mir vorstellen das es genau da timingprobleme gibt. das würde auch erklären warum es beim betrieb mit der camd2 nicht passiert. diese macht ja eigentlich fast nichts und muss nicht entschlüsseln etc, somit nimmt sie die daten schneller ab und der bus ist vielleicht früher frei. ich bin kein hw spezialist für die dbox, könnte mir aber so etwas in der richtung gut vorstellen. um das wirklich zu beurteilen müsste man aber die genaue techn. funktion der box kennen, und da noch niemand den enx wirklich verstanden hat (sonst hätten wir ja schon custom ucodes *g*) denke ich genau da fehlt es noch an allgemeinem wissen.

dachte ich mir schon. könnte es sein das 2x in verbindung mit dem enx chip und den diversen zusatzprogrammen die man so am laufen hat timingprobleme verursacht und das eine der ursachen ist? sind die phillips auch betroffen?

noch vielleicht eine kleine anmerkung: ich hatte ja berichtet das bei mir das zwitschern jetzt weg ist. meine ist eine 1xi schwarze sagem. ich vermute mal das die verschiedenen sagems alle verschieden stark und aus unterschiedlicher ursache zwitschern. es gibt wohl: graue sagem (ist die 1x oder 2x?) schwarze sagem 2x schwarze sagem 1x somit wäre es natürlich wichtig das du eine "extremzicke" beckommen würdest.

das wäre klasse. denn in der 12 würde die sectionsd prio angepasst.

Keywelt 2007 Squashfs September Image V1 Beta12 wird nicht mehr public getestet. bei der beta8 gab es bei mir noch zwitscherer, bei der 10 nur noch wenige, seit der 11 gar keine mehr (bei MEINER box. keine zu verallgemeinernde aussage) aber wie schonmal gesagt, ich vermute mehrere ursachen, vielleicht wurde eine dieser ursachen im cvs gefixt (oder zufällig umschifft). also im schlimmsten fall einfach mal abwarten und dann die final testen wenn sie public ist. so lange aber den daemon ausprobieren, damit wir eine funktionierende symptombeseitigung haben wenn es vielleicht mal wieder nicht funktioniert.

die einstellungen sind jetzt sogar auf den defaults(! ausser enx und avia watchdog sowie gtproc, welche natürlich angeschaltet wurden) des images. ich habe nie behauptet das liegt an den einstellungen, sondern muss irgendetwas neues im cvs oder im beta10/11/12 image sein. das einzige was ich sage ist das ich als tester für den daemon deswegen mangels masse ausfalle. btw: egal was ich einstelle kann ich keine zwitscherausfälle mehr provozieren. ich müsste also das beta image runterwerfen, was ich nicht tun werde :-)

welcher fix funktioniert? in obigem zitat wird von einem funktionierenden fix geredet. interessant wäre herauszufinden welcher das ist. btw: bisher immer noch keine zwitscherei bei meiner sagem. ich bin also ein schlechter kandidat zum testen des daemons.

@newcode: ich denke aber wenn man es schafft die box so stark zu entlasten das das timing kein problem wird dann schafft man es vielleicht 80-90% den hänger zu beseitigen. vergleich: vorherige betas lagen bei 40-50% cpu last => zwitschern durch die runterpriorisierung der sectionsd hat meine jetzt: 0-1% cpu last => keinerlei zwitschern mehr ich denke nicht das dies alle zwitscherfälle betrifft, da ich persönlich glaube das es mehrere ursachen gibt. aber der "timingfall" könnte damit erledigt sein. und natürlich hab ich hw-sections abgeschaltet, damit der enx nicht noch mehr zu tun bekommt und mit der box und sectionsd reden muss.

sorry das ich zzt nicht testen kann. hab deinen deaemon auf der box aber nicht aktiviert, da ich bisher noch keinen einzigen (!) zwitscherer mehr mit der b11 hatte.

gut zu wissen, das kanns auch bei mir gewesen sein. hab mitlerweile leider keine testfälle mehr. schaue seit der veröffentlichung der beta11+1h mit mgcamd fern und keinerlei hänger. ärgerlich. (btw: nur die beiden watchdogs aktiviert und gt-proc angeschaltet, sonst nichts verändert an den einstellungen).

mein problem ist erstmal das ich zzt gar keine zwitscherhänger mehr habe... aber kommt zeit kommt zwitschervogel :-)

tnx. nett wäre auch noch eine ausgabe (zuschaltbar) nach /tmp/avia-check.log in welcher die resets (am besten mit zeitstempel) mitgeloggt werden. damit wir auch sicher sind das der daemon zuschlägt *g* (im script hab ich mir das alles selbst eingebaut) die beta11 läuft übrigens bisher ohne hänger bei renice'ter sectionsd. bin mal gespannt.

in der beta 11 will ich erst mal testen ob ich ohne, nur mit renice runterpriorisiertem sectionsd, noch hänger hab. danach verifiziere ich das auch wirklich bei den hängern die proc/interrupts stehenbleiben. zur zeit sieht es mit der beta11 nämlich definitiv nicht so aus (alle einstellungen im auslieferungszustand gelassen um eine eindeutige testbasis zu haben) als ob bei hängern die interrupts weitelaufen. die box fühlte sich bei der beta 10 per telnet etwas träge sehr träge. ungefähr so wie die box ohne sectionsd renice bei der beta11. aber es war definitiv so das die kiste dauergeresettet hat ohne das das script weiterhin aktiv war. ich vermute die pollfrequenz war für unsere treiberkombi oder die spezielle box einfach so hoch das die änderung fast immer 0 war ;-) mach mal eine version die ein config-file in ihrem aufrufverzeichnis abfrägt in das man die pausenzeit eintragen kann. 2 werte brauchen wir eigentlich: watchdog-frequenz (alle wieviel sekunden wird aufgerufen. oder ms?) reset-pause (wie lange wird nach einem reset mindestens gewartet bis der wd wieder losläuft)

kann ich bestätigen, der daemon macht woch dauerreset.

kann man die priorität des daemons beim starten mit angeben? so könnte man den als "hintergrundprozess" laufen lassen damit er nichts anderes beeinflusst.

dazu kommt bei meiner box: vom einen tag zum nächsten isses mal mehr mal weniger. ich hab die ganze zeit schon eine regelmaessigkeit gesucht, aber jedesmal wenn ich was vermute beweist die kleine mir das gegenteil. deswegen vermute ich mehrere fehler welche alle das symptom "zwitschern" erzeugen. wenn wir also irgendwie eine ursache beseitigen sind immer noch andere übrig. beispiele? gerne: die ganze zeit dachten wir: enx-hänger sind alleine dafür verantwortlich. aber weit gefehlt: ich konnte definitv ab und zu hänger beobachten bei denen die interrupts weiterlaufen. also der enx weiter läuft! achja: und wenn man sie beobachtet passiert natürlich nix. die box muss also augen haben *g* sie läuft nämlich jetzt schon ewig durch ohne enxreset. ich sollte vielleicht mal den bsdice watchdog wieder abschalten um zu verifizieren ob es der ist. will aber noch bis zur beta11 warten bevor ich meine family weiter quäle *g* (wenn ich zu dem erlauchten kreis gehören sollte der sie bekommt)

schwarze sagem quarz: NDK:14 27.000 zwischern mal mehr mal weniger. aber ne andere frage: würde es nicht mehr sinn machen eine liste mit bauteilen zu erstellen die wir vergleichen? vielleicht ist es ja auch eine bestimmte serie netzteile, oder die kombination aus bestimmten quarzen mit speichern .... usw.

hat jemand mal einen link zum bild der hauptplatine einer schwarzen sagem und kann erklären wo genau ich dann was ablesen muss? hatte die kiste noch nie offen *g*

beim speicher ist der hersteller denke ich egal. wenn dann ist die reaktionszeit wichtig (60ns aus obigem post bei der nicht-zwitschernden). kann mal jemand ein bild posten was wir wo ablesen können? macht es sinn bei der gelegenheit gleich die modemkarte auszubauen? @newcode: so langsam wirst du mir unheimlich. was macht denn die neue erste schleife in deinem script eigentlich? den rest hab ich noch verstanden, aber jetzt hörts dann auf mit meinen fähigkeiten *g* aber nochwas anderes: wenn in manchen fällen das killen der sectionsd ohne enxreset die box entzwitschert, bedeutet das nicht das der enx dann gar nicht hängt? könnte es sein der der enx-chip irgendwie mit der sectionsd reden will, das nicht kann (weil die irgendwie nicht richtig läuft) und deswegen nicht mehr genug puffer/speicher/wasauchimmer hat um richtig zu arbeiten? wenn obiges technisch möglich wäre dann ist das eventuell doch wirklich ein ansatz zur problemlösung. aber dazu eine andere frage: was in der box benutzt eigentlich den enx genau? bzw was macht der chip ganz genau? vielleicht sollten wir da mal analystisch drangehen :-) wenn mir jemand die infos als link oder per pm geben kann auch ok. wir müssen ja nicht den thread komplett zuposten.

@bahnbooster: kein dank an mich, ich teste das nur! das script haben wir newcode zu verdanken. der watchdog wurde wie ich das sehe laut der statusanzeige NICHT ausgelöst. komisch ist das schon.

ich hab in der 10'er beta jetzt auch eine nette beobachtung gemacht: einstellungen wie in der beta7 führten dazu das oft nach dem umschalten das bild schwarz wurde. rezap half. aber jetzt kommts: ich hab dann mit allen möglichen einstellungen rumprobiert, nichts half. dann hab ich im epg-menü das dsnice (heisst der so? ich bin mir nicht mehr sicher schaut selbst nach) watchdog aktiviert. seit dem lief die box ohne schwarzbilder beim umschalten. ok. aber jetzt kommt es richtig dick: danach hatte ich auch nur noch sehr selten zwitschern, selbst ohne script (ich lasse mir die resets durch das script in ein log mitschreiben, deswegen kann ich sehr genau sagen ob einer statt gefunden hat). da dieser watchdog wenn ich richtig vermute(!) (ich hab nichts dazu gefunden) auch mit dem epg zu tun hat könnte das deine beobachtung nochmal stützen. natürlich könnte das zwitschern auch mit cpu last zu tun haben und je mehr man aktiviert desto besser wird es *g* was macht dieser watchdog eigentlich genau?