niemand0815

@faze: ja, schaut so aus. nur anders. es wird nur geprüft ob noch avia interrupts kommen und dann ein enxreset gemacht wenn keine kommen. generell sollten das aber erst mal nur erfahrene nutzer einbauen, denke ich. @newcode: hier auch nachdem ich auf "deine" avia und ucode combi gewechselt hab. es scheint je nach avia version unterschiedliche interruptmengen zu geben (irgendwie war das ja zu erwarten) und bei manchen avias kommen trotz hängendem enx noch interrupts an. mit der von dir beschriebenen version aber nicht. probleme scheint es manchmal beim umschalten zu geben, schwarzbild mit ton oder bildhänger mit normalem ton. ich gehe mal vom fehlenden "umschaltreset" aus. der ist ja glaube ich in den betas noch nicht drin, wenn ich mich nicht irre. oder?

hab bei mir mal auf die 21 gewechselt, seit dem habe ich oben beschriebene hänger trotz interrupts. ich teste noch andere einstellungen und geh dann mal auf die 014 welche in der beta7 drin ist zurück. welche avia-treiberversion wäre auch denke ich noch wichtig, eventuell verhalten die sich unterschiedlich.

das hoffe ich auch. vielleicht würde das dann die ursache lösen statt an den symptomen zu basteln. @newcode: hatte eben wieder einen hänger trotz script. was mir dabei auffiel: es kamen pro sekunden 200-300 interrupts für den avia. normalerweise hab ich da immer nur 100-150 gesehen. kann es sein das zu viele interrupts auch ein symptom für einen hängenden enx sind? auf jeden fall konnte das script deswegen nicht loslaufen. manueller enx-reset hat sofort geholfen. eventuell zeigt sich hier das wir mehrere symptome haben die sich für den user gleich auswirken (zwitschern), aber verschiedene ursachen haben. gegen das primärproblem hilft das script definitiv (ich konnte bisher nie 24h einen sender laufen lassen). nur zur vollständigkeit: wie sind deine ucode und sonstigen einstellungen? (vielleicht per pm um den thread nicht vollzumüllen). gibt es noch irgendwas das ich bei einem sochen hänger mal überprüfen kann?

also 24h problemlos, mit nur einer sonderheit: einmal war der hänger mit (!) interrupts. bild gehängt, ton zwitschernd, aber immer noch knapp 1ir/sekunde erst nach knapp 30 sekunden haben die aufgehört und das skript hat gezogen. das brauchte dann 6 resets (mit verzögerung) bis das bild wieder stabil lief (und der ton). ich denke aber das war ein sonderfall.

ja, das neue script. bei mir hatte ich nur auf animal planet zwitscherer heute. und extrem wenig... mist. immer wenn mans provozieren will. hab sogar den ap neben der box auf volle leistung hochgepumpt, aber nur wenig erfolgt. welche ucode und gtproc settings etc. verwendest du? evtl müssen wir und da aneinander angleichen um aussagekräftig testen zu können. btw: schlagt mich nicht, aber wo muss ich nochmal scripts plazieren damit die im hauptmenü erscheinen? btw2: und mit dem sleep 1 drin hatte ich nicht mal nen richtigen freeze. EDIT: so, habs mir jetzt mal in die start-neutrino eingebaut. * beim scriptstart benötigt man ein "sleep 15" um resets beim booten zu verhindern. * durch den "sleep 1" vor der else braucht man nur 1 reset pro hänger, nicht mehr 3. todo: bei "kanal nicht verfügbar" und bei sendern ohne vogel darf das script nicht zuschlagen. wobei zweiteres untragisch ist (passiert ja eh nix da es nie hängenbleibt). und ersteres ist auch unkritisch, da es dort sowieso egal ist (und durch den sleep vor der else wird recht selten resettet, so das es denke ich auch nicht zu anderen problemen kommen sollte). #!/bin/sh # avia-check.sh v0.201 sleep 15 OLDCOUNT=0 while sleep 1; do COUNT=$(grep avia$ /proc/interrupts) if [ "$COUNT" = "$OLDCOUNT" ]; then /bin/enxreset 1>/dev/null 2>/dev/null AUDIO=$(/bin/pzapit --getpids | grep "*audio" | cut -b 8) /bin/pzapit -a $AUDIO sleep 1 else OLDCOUNT=$COUNT fi done

habs mal ausprobiert, und es wirft den enx-reset an sobald das bild hängt. aber: danach war der ton weg. was mir auffiel: es werden in kurzer zeit 3-4 resets hintereinander abgefeuert. eventuell verursacht das ja den tonaussetzer. ich versuch es jetzt mal mit pausen vor den else. btw: kaum das man so was probiert tritt es natürlich nur noch selten auf. so ein mist. einmal hatte ich auch einen bild schwarz, aber ton da als ergebnis. ich vermute aber wirklich die massiven enx-resets als ursache dafür. EDIT: * bei kanal nicht verfügbar macht er dauer-enx-reset bis man den kanal wechselt * mit sleep 1 vor der else scheint es bei mir stabier zu laufen. ich hab beim zappen einen hänger gar nicht bemerkt.

ich würde sagen wir sollten vielleicht im NP bereich einen dev-thread dafür aufmachen. bin auch gerne bereit zu testen.

ich würde sagen wir sollten vielleicht im NP bereich einen dev-thread dafür aufmachen. bin auch gerne bereit zu testen.

so, und nochwas witziges: die 1.25 g* mit mgcamd zusammen laufend führen dazu dass es fast kein gezwitscher mehr gibt. somit muss die g ja irgendwas machen das die mg besser lauffen lässt bzw das enx hänger entweder verhindert oder beseitigt. zumindest sind das seit gestern meine beobachtungen (singlecam=vielzwitscherei, multicam=weniggezwitscher). wie immer ist das problem beim zwitschern das es natürlich auch zufall sein kann, also beobachte ich mal noch weiter. EDIT: mööps.. kommando zurück. kaum hatte ich es geschrieben hatte ich 5 zwitschervögel hintereinander. naja, wieder mal zu früh gefreut. zeigt mir aber wieder das es extrem zufällig auftritt. *sigh*

@xander: wenn das so stimmt dann müsste es doch auch ohne g* möglich sein das log auszuwerten und den reset zu starten, oder sehe ich das falsch? oder wird das log von der g* selbst erzeugt? dann müsste man schauen ob man eine andere cam mit so einer funktion ausstatten kann.

also von der grundidee her könnte es schon klappen. wenn auf irq's vom enx geprüft wird und diese durchs hängenbleiben komplett ausbleiben könnte es gehen. aber um das zu probieren würden wir ja ein entsprechend vorbereitetes image benötigen. ein anderer ansatz wäre zu prüfen ob sich das bild ändert oder nicht. wenn sich das bild 1 sekunde lang nicht ändern dann könnte man einen reset machen (problematisch könnte das dann bei "standbildsendern" werden, was man dadurch lösen könnte das man pro minute nur einen reset erlaubt oder so). irgendwie muss das berühmte g ja auch feststellen das der enx hängt und dann automatisch resetten. oder hängt er damit gar nicht?

um wieder zum thema zurückzukommen: was ist denn für die irq-überwachung nötig? wie kann man das ins beta7-image implementieren? können wir das einfach so machen oder müssen die beta-devs ran? oder ist vielleicht schon alles drin was wir brauchen und wir müssen nur das script einfügen? ich denke wenn es funktioniert wäre es mal ne richtig tolle innovation.

also, ich würde sagen schreit nicht zu früh: nach 2h dauerlauf ohne vogel hab ich danach dafür alle 10 minuten einen gehabt. (manche sagen ich habe immer einen, aber ich denke ihr wisst was ich meine). die einzig sinnvolle lösung ist wohl solange wir die eigentlich ursache nicht kennen das einbauen eines automatischen reset wie ja vorher schon beschrieben.

deswegen wäre die oben beschriebene methode eines automatischen enx resets auch denke ich genial. wenn sie funktioniert... *g* zur beta7: auch damit habe ich noch hänger, egal mit welchem ucode. nur witzig ist: es scheint mir bis jetzt mit dem ucode 1a so zu sein das diese nur beim umschalten auftreten. muss das aber für eine klare beurteilung noch weiter beobachten über 3-4 tage. fakt ist: hab seit heute die beta7 drauf und hatte mit der 1a noch keinen laufzeitvogel erwischt. eben nur umschaltvögel. dank enx reset plugin gings dann recht flott wieder und hielt auch. denn wie gesagt: es konnte auch vorher schon mal passieren das es lange ging. deswegen darf man zwar hoffen, aber erst mal abwarten bis man zu optimistisch ist. die ursachen für das vögelchen scheinen ja diverse zu sein.

ungefähr alle 5-30 minuten. manchmal hält es auch 2-3h durch ohne. aber die aktuelle beta hat gt-proc drin, somit hab ich gleich das enx reset plugin nachgerüstet und es geht. sollte es dann möglich sein die neue "idee" für die zicken zu implementieren? also ein enx-reset (ist jetzt in bin drin) wenn keine interrupts kommen?

wäre es nicht schön lösungsversuche für das zwitscherproblem in der neuen beta des kw images zu testen? da kann ich genau wegen des zwitscherproblems nämlich nicht mittesten :-( (kein enx-reset = regelmässiger reboot nötig bei meiner sagem 1xi schwarz).