Ich würde das Problem auch nicht überbewerten ... das sind (ich spekuliere/interpretiere jetzt mal, wie ich das verstehe ... Korrekturen und bessere Erklärungen sind mir jederzeit willkommen) wohl nur Warnungen, wenn bei der Behandlung von Interrupts für die DECT-Anbindung (ob auch für AHA oder nur für Telefonie, will ich gar nicht wissen) zu viel Zeit vergeht und die Latenz der Interrupts damit zu hoch wird.
Wenn das nicht "in time" erfolgt, kommt sicherlich die DECT-Kommunikation durcheinander (bei der 7412 kann sich ja das "pcm" im Treibernamen eher nicht auf die ISDN-Funktionen beziehen und woanders wüßte ich jetzt nicht, wo da TDM (was für mich in diesem Kontext für "time division multiplexing" steht) zum Einsatz kommen sollte - dabei würde ich aber verstehen, daß es eben zeitkritisch ist) und wenn das zu oft passiert oder die Verzögerungen zu groß bzw. zu viele werden, dann startet die Box mit der "kernel panic" einfach neu in der Hoffnung, daß es nur ein "verklemmter Prozess" war, der da die Resourcen über Gebühr beansprucht hat.
Wenn ich Freetz richtig verstehe, würde das sogar zu meiner Beobachtung mit dem Absturz beim ersten Start mit einem Freetz-Image passen, denn da werden ja wohl auch erst einmal die "Standardeinstellungen" hergestellt und gesichert, wenn die Box in Bezug auf die Freetz-Konfiguration noch jungfräulich ist ... sprich, der erste Start könnte am Beginn eine höhere Last erzeugen als alle weiteren.
Wenn sich die Box dann erst einmal etwas ge"settled" hat, treten diese Warnungen nach meiner Beobachtung auch nur noch sehr selten auf.
Warum sie überhaupt entstehen bei deaktivierter DECT-Basis, ist mir allerdings auch ein Rätsel ... aber der pcmlink.ko könnte auch noch für die Anbindung der Reste dieser C55x-DSPs zuständig sein, die meines Wissens in all den eingesetzten Chipsets auch noch vorhanden sind und vermutlich die Echo-Cancellation und auch Encoding/Decoding für einige "übliche" Codecs machen, denn das ist für den Hauptprozessor dann doch etwas zu speziell (zumindest EC) und dafür wären die meisten Prozessoren wohl auch zu langsam, wenn die das in Software lösen müßten und möglichst noch für 3 Gespräche parallel.
Ich bin ja immer noch der Meinung, daß die Beschränkung der Boxen bei den möglichen parallelen IP-Telefonaten auch darauf zurückzuführen ist, daß da die DSPs ansonsten nicht ausreichen.
Jedenfalls halte ich diese Warnungen im Betrieb nicht für relevant ... ich würde sogar sagen, daß ich sie bei der originalen Firmware auch schon gesehen habe, wenn ich es am Beginn des init-Prozesses (da startet meiner Meinung nach eine Art Messung beim Laden des Treibers) mit dem Starten eigener Programme übertrieben hatte.
- - - Aktualisiert - - -
Inzwischen glaube ich eher an einen Zusammenhang mit einer anderen Gemeinsamkeit zwischen der 7412 und der 7430 ... das sind beides Modelle, die keinerlei NOR-Flash mehr haben (weder mit Data-Bus noch seriell) und bei denen eine Emulation des TFFS in einer einzelnen NAND-Partition erfolgt. Dieser "TFFS im NAND"-Treiber ist auch vergleichsweise neu gewesen ... da würde ich nicht ausschließen wollen (so sagt man das heutzutage wohl korrekt), daß da noch der eine oder andere Bug drin schlummert, der eben von Freetz nun getriggert wird. Das gab es bei der libusb-irgendwas ja auch, daß (nur leicht) unterschiedliche Konfigurationen der uClibc am Ende zu einer SEGV führten.
Bei der 06.50 startet das Freetz-Image - wie oben beschrieben - irgendwann ohne Probleme ... mit dem neuen Kernel wurde aber auch der TFFS-Treiber weitgehend "ausgemistet" und ist als "TFFS3" wiederauferstanden, diesmal von Beginn an mit der Unterstützung unterschiedlicher Speicher-Formen ... von "richtigem" NOR- über SPI- bis NAND-Flash und auch der Teil, der bei wirklich wirklich schlimmer Panik noch irgendwelche Spuren sichern soll, wurde komplett überarbeitet (die anfänglichen Konfigurationsverluste mit der 06.35 bei einigen hier im Forum, sind sicherlich auch auf diesen Neubau zurückzuführen).
Mit 06.30 geht die Box in eine ca. 45-48 sekündige Boot-Schleife ... das hat mit dem Aufbau des Images oder fehlenden Libs für die Busybox garantiert nichts mehr zu tun. Ich habe keine serielle Konsole dran an der 7412 ... mal schauen, ob ich noch ein Kabel mit Pegelwandler in einer Bastelkiste finde.
Auf die Idee mit dem Unterschied beim TFFS brachte mich dann die Feststellung, daß (nach der Umschaltung auf das alternative System) im TFFS keine "crash.log" bzw. "panic.log" vorhanden war (bzw. die betreffenden Daten im TFFS fehlen, auf den Kern der Story, was ein TFFS-Node ist, will ich jetzt mal nicht weiter eingehen).
Wenn es für die 7430 ebenfalls eine 06.50 geben sollte, könnte man also auch mit der mal probieren, um dann die 06.30 einfach auszulassen in Freetz.
Am Ende stellt sich mir de Frage, ob es sich tatsächlich lohnt, einem (vermutlichen) Fehler in der 06.30 nachzugehen, wenn die 06.50 verfügbar wäre (das mit dem "replace kernel" kriegen wir irgendwann auch in den Griff) - ein Downgrade von einem 3.10er-Kernel auf einen 2.6er ist auch mit Freetz nicht ohne weiteres möglich.
AVM hat ja nicht nur aus Sicherheitsgründen das Downgrade (aus dem laufenden System heraus ja auch nur) "abgeschafft" ... es ist ja aus objektiven Gründen nicht möglich, ein älteres Image (wo filesystem.image eben noch direkt ein SquashFS3-Image mit dem Inhalt von /wrapper ist) ohne zusätzliche Tools wie unsquashfs mit einem 3.10er-Kernel zu behandeln, weil der das schlicht nicht mounten kann (das muß ja auch in "modfs" mit "unsquashfs" seziert werden).
Erst wenn das Downgrade von AVM innerhalb einer Kernel-Generation nicht mehr zugelassen wird, erst dann stehen dahinter (vermutlich/hoffentlich) Sicherheitsgründe. Beim Verschwinden der ganzen älteren Recovery-Versionen (denen ist die Kernel-Version im zu überschreibenden System schlicht egal) gilt das natürlich auch ... da sollte wieder "Sicherheit" das Thema (gewesen) sein.
