noomad

Neuer User
Mitglied seit
9 Jul 2017
Beiträge
38
Punkte für Reaktionen
2
Punkte
8
Hallo,

von einem Bekannten habe ich eine tote 7490 zum Testen bekommen. Netzteil ist funktionsfähig. Die Box rührte sich aber nicht. Nichtmal eine LED leuchtete.
Zunächst habe ich die 3 Pins für die UART-Schnittstelle eingelötet um zu schauen ob da irgendwas ausgegeben wird. Alles tot.
Zum Testen habe ich ein Labornetzteil angeschlossen und auf 2A begrenzt. Nach dem Einschalten hat die gleich 2 A gezogen. Naheliegend dass irgendwo ein Kurzschluss vorliegt.

Nach eingehender Prüfung habe ich mittels Thermocam und nachmessen einen defekten 10µF SMD Keramik-Kondensator in der Baugröße 0805 gefunden der einen Kurzschluss hatte.
Nach dem auslöten zeigt die Box erste Lebenszeichen. LED und ein die UART-Schnittstelle funktionieren wieder. Logfile ist angehängt. Kann mir jemand anhand der Logfile sagen wass da zum Neustart führt? Kennt jemand den genauen Aufbau der Fritzbox und kann mir sagen welchem Chip oder welcher Funktion durch den defekten Kondensator einen Kurzschluss bekommen hat? Ich habe den Bereich rot umrandet. Die Bauteilgruppe ist eine Stromversorgung. Von 12 V Eingang wird auf 3,3 V runtergeregelt.
 

Anhänge

  • IMG_20200402_172640_3.jpg
    IMG_20200402_172640_3.jpg
    999.1 KB · Aufrufe: 62
  • putty_log.txt
    61.9 KB · Aufrufe: 33
Zuletzt bearbeitet:
Ist das Problem (exakt so, was den Stack-Trace angeht) reproduzierbar?

Es ist nicht direkt zu sehen, ob und wenn ja, welche Hardware-Komponente hier Probleme machen könnte.

Es erfolgt (warum kann man (bzw. ich) nicht erkennen) ein Zugriff auf eine Adresse, die rein theoretisch außerhalb des Kernel-Speichers liegt, weil bei AVM sich eigentlich fast alles, was den Kernel angeht (und dem Stack-Trace nach sieht das so aus, als erfolgte der Zugriff aus einem "kernel worker thread"), in KSEG0/KSEG1 abspielt und da hat eine Adresse eigentlich immer das höchstwertige Bit gesetzt.

Daher kommt es hier auch zu einer "bad virtual address" und in der Folge stürzt der Kernel ab, weil er wohl für diese virtuelle Adresse gar kein Mapping auf irgendeine physikalische hat und normalerweise verwendet AVM auch keinen Swap-Space o.ä. - somit ist ein "echtes Einlagern" von Speicherseiten weder notwendig noch möglich.

Andererseits ist da offensichtlich irgendeine neuere Labor-Version installiert (07.19-76429) und deren Innereien habe ich zwar in einigen Punkten schon mal versucht zu untersuchen, aber definitiv noch nicht hinsichtlich der Verwendung von virtuellem Speicher oder gar einem Speicherschutz-Mechanismus. Da kommt ja dann "nqcs" als SMB-Server dazu und für diesen Daemon wurde von AVM auch noch AppArmor in das System eingebaut und offenbar für den dann auch das Audit-Framework noch aktiviert (u.a. der neue Kernel-Parameter mit "audit=1" beim Start).

Alles das ist für diese neue Labor-Reihe bisher nur wenig erforscht (ich kenne jedenfalls auch niemand anderen, der - hier oder anderswo - zu diesen Themen schreibt oder geschrieben hat) und ich würde hier tatsächlich mal hingehen und das AVM-Recovery-Programm auf die Box loslassen und dabei das Protokoll auf der Seriellen ebenfalls mitlaufen lassen und sichern. Warum?

Dieses Recovery-Programm führt ja am Ende auch nur dazu, daß ein Kernel und ein Dateisystem in den Hauptspeicher geladen und dort gestartet werden. Im Rahmen der Initialisierung stellt das System dann fest, daß es aus dem RAM gestartet wurde und schreibt sich selbst in den NAND-Flash der Box, bevor es diese anschließend noch einmal neu startet, wobei das System bei diesem zweiten Anlauf dann eben aus dem Flash geladen wird.

Damit könnte man (a) ausschließen, daß es am Ende nur ein Problem mit der vorliegenden Labor-Version ist und hätte (b) eine Information, ob die ältere Firmware in der Lage war, sich in den Flash zu schreiben (das erfolgt normalerweise schon vor dem Laden des Piglet-Treibers für DECT und Telefonie allgemein, die man in Deinem Protokoll noch sehen kann) und das möglichst noch ohne Fehler. Wenn dann noch (c) das ältere System, für dessen Start und das dabei erzeugte Protokoll viel mehr Erfahrungswerte vorliegen, durchläuft, wäre der Schuldige schon (teilweise zumindest) gefunden und wenn das nicht der Fall ist, kann man mit diesem Protokoll besser auf die Suche gehen.

Wobei Du generell noch Deinen Teil dazu beitragen könntest, daß man die Abläufe besser sieht ... wenn Du unmittelbar nach der Zeile
Code:
[avm_debug] redirecting kernel-messages (/dev/debug)
auf der seriellen Console einfach noch einmal "Enter" drückst, wird es nicht länger dunkel für die nächsten neun Sekunden, wie es im bisher gezeigten Logfile von Sekunde 16 bis 25 der Fall ist, sondern dann sieht man auch noch, was ansonsten im Rahmen der Initialisierung an Skripten gestartet wird (und Ausgaben auf "/dev/console" erzeugt).

Aus dem bisher sichtbaren Stack-Trace wird man jedenfalls nicht wirklich schlau und offenbar hat AVM auch den Backtrace-Dumper noch einmal deutlich verändert und jetzt muß man erst mal wieder versuchen zu verstehen, was die ganzen Daten, die da im Panic-Log ausgegeben werden, im Einzelnen bedeuten sollen. Daher wäre es auch hierfür wieder schlauer, sich erst mal mit einer älteren Version vorwärts zu tasten.

Wie aus einem Hardware-Problem jetzt eine ungültige Speicheradresse werden soll, kann man nur spekulieren ... eine Idee wäre ein "Underrun", bei dem von einem (noch gültigen) Pointer eben ein zu großer Wert abgezogen wird und damit eine Adresse unterhalb von 0x80000000 entsteht oder auch ein "Overflow", wo ein zu großer Wert zu einer Adresse addiert wird und damit am Ende dann ein Überlauf in das Bit 2 ** 32 eintreten würde, das bei einem 32-Bit-Register (2 ** 0 bis 2 ** 31) eben nicht mehr existiert. Wobei für einen Overflow ist die "falsche virtuelle Adresse" mir schon fast wieder zu groß, denn 0x72c08f48 läge deutlich näher an 0x8000000 dran. Auch sieht es so aus, als wäre die Adresse 0x72c08f44 ein Parameter in irgendeinem Funktionsaufruf (sie steht in einem der Registerdumps in der Zeile, die mit "$4" beginnt - ich müßte aber erst nachschauen, welchen symbolischen Namen $4 bei MIPS hätte) und dann wäre ein Zugriff auf 0x72c08f48 halt ein Zugriffsversuch auf die Verschiebung 4 für einen Pointer mit diesem Wert.

Aber das sind alles nur "Mosaiksteinchen" ... ich kenne den State-Dump aus dem neuen Kernel bisher nicht gut genug (mir ist noch nicht mal aufgefallen, daß AVM da einen neuen oder geänderten verwendet, weil man dafür natürlich auch erst mal eine Box braucht, die an der passenden Stelle in Panik gerät), um hier wirklich etwas feststellen zu können - mit einer älteren Version stehen die Chancen derzeit noch deutlich besser und mit ganz viel Glück, ist das tatsächlich ein Problem, was nur mit der Labor-Reihe auftritt und ggf. mit einer aktuellen Version sogar schon wieder behoben ist.

Eigentlich käme jetzt im Ablauf (das letzte, was man sieht ist das versuchte Laden des Piglets für die ISDN-Funktionalität) das Laden des Piglets für POTS und danach müßte eigentlich protokolliert werden, welcher Modus nun tatsächlich (für die externe Telefonie) verwendet wird. Parallel dazu würde das Dateisystem in der NAS-Partition gemountet (YAFFS2). Was da bei Dir nun schon gestartet wurde und was da ansonsten noch zuvor geschah, sieht man wieder, wenn Du das Umschalten auf die ausschließliche Ausgabe nach "/dev/debug" mit dem o.a. Tastendruck einfach übergehst bzw. damit dafür sorgst, daß auch auf "/dev/console" wieder ausgegeben wird.

Also meinerseits zwei Vorschläge, auf deren Ergebnis ich gespannt warte: Erstens Installation einer älteren Version, mit Protokollierung auf der seriellen Schnittstelle, und zweitens bei jedem künftigen Protokoll an der gezeigten Stelle das Betätigen der Tastatur nicht vergessen ... dann sieht man deutlich mehr.

EDIT: Ich korrigiere mal den Zeitpunkt, wann man die Taste drücken sollte, eher auf deutlich früher ... irgendwann zwischen dem Entpacken des Kernels (das ist abgeschlossen, wenn die Punkte am EVA-Prompt komplett sind und die Ausgaben mit Zeitstempel beginnen) und der 4. bis 6. Sekunde (wo dann erst mal die Netzwerk-Interfaces initialisiert werden und jede Menge Ausgaben mit "avmnet_irgendwas" als Quelle zu sehen sind) sollte der Tastendruck schon erfolgen.

Ca. bei 6 Sekunden wird das Root-FS gemountet (zunächst noch die YAFFS2-Partition, das "pivot_root" auf das SquashFS kommt ja erst danach) und dann kommt - bei der 7490, wie bei allen VR9-Boxen - auch schon das "flash_update", das hier ja noch aus der ersten "/etc/inittab" gestartet wird. Und es ist nicht wirklich verkehrt, wenn man schon zu diesem Zeitpunkt dann die Ausgaben auf "/dev/console" verfolgen kann ... daher vergiß das mit der oben stehenden Zeile. Richtig ist das Drücken der Taste irgendwann vor bzw. spätestens beim Mounten des Root-FS aus der NAND-Partition.
 
Zuletzt bearbeitet:
Hier ist die vollständige logfile "vor" dem Recoveryversuch.

--

Hier ist das recovery log.

--Zusammenführung Dreifachpost gemäß Boardregeln by stoney

Die Frage welches Bauteil ich da durch auslöten der Kondensatoren stillgelegt habe ist wohl beantwortet. Die zwei USB-Ports liefern keine 5 V. Anbei zwei Bilder. Eines von meiner 7590 wie es aussehen sollte, eins von der 7490 ohne Stromversorgung am USB-Port.
 

Anhänge

  • putty_log_20200404_b4recovery.txt
    38.8 KB · Aufrufe: 13
  • putty_log_20200404_recovery.txt
    81.2 KB · Aufrufe: 8
  • 7590_USB_5V.jpg
    7590_USB_5V.jpg
    78.2 KB · Aufrufe: 32
  • 7490_USB_no5V_.jpg
    7490_USB_no5V_.jpg
    283.9 KB · Aufrufe: 30
Zuletzt bearbeitet:
Trotzdem dürfte das nächste Problem erst einmal irgendwo im FPGA für die Telefonie-Funktionen zu suchen sein - das heißt noch nicht, daß USB nicht ebenfalls ein Problem haben kann (auch wenn Du in #1 für den Schaltregler ja noch 3,3 V als Ziel angibst).

So müßte es eigentlich aussehen im Log:
Code:
[   16.250000][1][piglet]dect144xx_file_process: upload of '/lib/modules/dectfw_secondlevel_441.hex' successfull
[   18.280000][1][piglet]bitfile for autodetect '/lib/modules/bitfile_isdn.bit'
[   18.280000][1][piglet]try to preload in progress-context: /lib/modules/bitfile_isdn.bit
[   18.900000][1][piglet] bitfile 72761 bytes done
[   24.000000][1][piglet]use preload[0] /lib/modules/bitfile_pots.bit
[   24.580000][1][piglet] bitfile 72761 bytes done
[   24.580000][1][piglet]-> POTS-Mode
[   24.680000][1][piglet]TDM: FS: 7995 Hz CLK: 2047700 Hz
[   25.230000][0]yaffs: dev is 32505861 name is "mtdblock5" rw
[   25.230000][0]yaffs: passed flags ""
[   25.230000][0]yaffs: yaffs: Attempting MTD mount of 31.5,"mtdblock5"
und bei Dir bricht es beim Laden irgendeines Firmware-Files in den FPGA-Chips - offenbar ja auch mit wechselnden ungültigen Adressen, denn das zweite Protokoll zeigt zwar prinzipiell auch ein Problem, was aus einer ungültigen Adresse resultiert, aber aus einer anderen und darauf zielte meine Eingangsfrage, ob das Problem auch exakt so reproduzierbar wäre - dann ab.

Das Kommando, was vermutlich (nein, eher "wahrscheinlich") den Abbruch verursacht, ist das "modprobe" in der Datei "/etc/init.d/S11-piglet" und da es da nicht direkt eine CONFIG-Variable gibt (ggf. wertet das LKM "Piglet_noemif" die aus, aber das LKM ist "closed source" und so sollte man erst mal den Rest der Box noch prüfen, bevor man sich an Versuche mit dem "Abschalten" von Teilen der Firmware über solche Variablen macht), würde ich einfach hingehen und diese Datei aus dem Dateisystem entfernen (oder eben anderweitig so ändern, daß das "modprobe" nicht zum Zuge kommt).

Das geht aber nur durch eine Installation einer angepaßten Version (Aktionen: Auspacken, Datei löschen, Einpacken, dann Installieren) und nicht mehr "nachträglich" in der im Moment installierten Firmware.

Da kann man dann auch erst mal "Inventur" machen, wenn die Firmware nicht länger crasht (oder erst später), denn ein durchgeschlagener Kondensator hat sicherlich auch seine Ursachen und ggf. hat diese - eigentliche - Ursache sogar noch weitere Schäden angerichtet, so daß es in der Summe u.U. fraglich ist, ob sich Reparatur wirklich lohnt.
 
Kann man nicht zum Testen einen Bootparameter mitgeben damit modprobe nicht versucht den Treiber zu laden?
 
Ich bin mir nicht sicher, ob ein "blacklisting" per Kernel-Command-Line (a) beim AVM-Kernel wirkt und (b) auch ein explizites Laden über einen Aufruf von "modprobe" verhindert (der ja in der "S11-piglet" erfolgen würde) und nicht nur ein automatisches und implizites Laden. Wenn ich mich richtig erinnere, wird auch das implizites Laden eines solchermaßen "blacklisted module", wenn das eine Voraussetzung für ein anderes wäre, nicht durch das Blacklisting verhindert.

Aber festlegen will ich mich da nicht ... mußt Du halt selbst mal mit "blacklist_modules=module_1,module_2,..." austesten - wenn Du das sauber als Kernel-Parameter setzen kannst. Das ginge theoretisch über "kernel_args", "kernel_args1" oder "kernel_args_tmp", aber einige Bootloader bei einigem Modellen ignorieren das auch mal und bauen die nach ihren eigenen Vorstellungen zusammen.

EDIT: Quatsch, der korrekte Parameter heißt "module_blacklist" (https://lore.kernel.org/patchwork/patch/695646/) ... ändere ich oben aber nicht mehr, sondern die Korrektur hier muß reichen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.