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.
