[Problem] FritzBox 7530 AX (1&1 Branding) stürzt sporadisch ab

[B612]

Aber ich denke viele junge Leute müssen erst mal googel was es bedeutet da es doch inzwischen sehr selten verwendet wird.

 

[PeterPawn]

Wenn sie dann alle gefundenen Ergebnisse auch lesen wollen (die Angabe ist ja nur "ungefähr"), ist es mit dem "jung" auch schnell vorbei:

 

[theGamer93]

Ja komisch. Irgendwie läuft die Box seit gestern 15 Uhr stabil. Ich habe vorher die Box vorsichtig aufgemacht und das Wärmeblech neu positioniert und an das Wärmeleitpad gedrückt. Ob der BCM eventuell ein Problem mit der Verlötung hat (BGA) und ein paar Kontakte durch das andrücken wieder Verbindung habe? Ich prüfe das mal weiter und gebe euch bescheid.

 

[Karl.]

Unwahrscheinlich, es sei denn, beide Geräte stammen aus einer Charge.

 

[theGamer93]

Beide Geräte? Wie meinst du das?

 

[Karl.]

Die 7590AX wurde doch mal getauscht, oder irre ich?

Liegen die Seriennummern beider Boxen nah beieinander, also der 1. Block aka X123 würde erstmal jeweils reichen, um meine Vermutung ggf. zu widerlegen.

 

[theGamer93]

Nö. Die Box wurde nie getauscht. Ich hatte eine 6591 bei Vodafone als Mietgerät und habe gekündigt. Die 7530AX habe ich bei eBay gekauft.

 

[PeterPawn]

und ein paar Kontakte durch das andrücken wieder Verbindung habe?

Und das führt dann dazu, daß DECT-Frames verstümmelt werden (DAS ist im Panic-Log ja deutlich)? Und in dem Monat, bevor die DECT-Geräte dann zur 7530ax umgezogen wurden (s. Deine eigenen Erklärungen, was sich geändert hat), ist so ein Kontaktproblem auch nie aufgetreten? Wenn die Box bzw. die CPU nach der Übernahme aller Aufgaben dann so heiß wurde, daß sich Lot verflüssigte (ja, auch nur weich wurde), dann hättest Du vermutlich noch ganz andere Probleme und solltest die Box nicht zu weit von einem Rauchmelder entfernt betreiben.

 

[theGamer93]

Und tatsächlich ist die Box heute wieder abgestürzt.

Ich habe das Log diesmal als .txt angehangen und vorher die IP-Adressen gelöscht.

Und wieder ist es ein DECT Error, so wie ich das sehe. Wieso nur 33min Uptime? Weil es kurz vorher einen Stromausfall gab, ich habe die Box dann von der Steckdose getrennt und als der Strom wieder da war, wieder eingesteckt. Hab das nur gemacht um eine eventuelle Überspannung o.Ä. zu vermeiden. Also die Abstürze passieren wirklich super zufällig und spontan.

Mal sehen was AVM so macht. Ich habe direkt Supportdaten versendet und mein Ticket aktualisiert.

 

[frank_m24]

Ich bin nicht davon überzeugt, dass DECT ursächlich für den Crash ist. Im zweiten Log sieht man gar nichts davon, und im ersten mogeln sich zwar DECT Fehler in den Backtrace, scheinen aber aus einem komplett anderen Ausgabeprozess zu kommen. Die DECT Probleme scheinen eher ein Folgeproblem des zuvor aufgetretenen Crashes zu sein. Zumal die gecrashten Prozesse ebenfalls nicht unmittelbar mit DECT in Verbindung stehen.

Ich weiß ja nicht, ob der swapper Prozess bei AVM das tut, was swapper früher so tat. Aber wenn dem so ist, dann deutet das eher auf ein Speicher Problem hin, als auf ein DECT Problem.

 

[theGamer93]

Bleibt die Frage wieso eine Fabrikneue 7530 AX (ich hab die Schutzfolien abgezogen und das Siegel gebrochen) Speicherprobleme hat und warum das nur sporadisch auftaucht. Heute Nacht um 4:20 gabs nochmal nen Neustart.

 

[frank_m24]

Das mit den Speicherproblemen ist eher Spekulation, wenn Swapper noch das tut, was es in den 80ern tat. Ob das heute noch so ist, keine Ahnung. Vermutlich eher nicht, das Kernel Scheduling hat sich seit dem doch sehr verändert.

Lief ein DECT Telefonat als die Box crashte? Hast du DECT mal deaktiviert? Dann könnte man eingrenzen, ob DECT eine Rolle spielt.

 

[PeterPawn]

Unable to handle kernel paging request at virtual address 9fe42d78

vs.

Unable to handle kernel paging request at virtual address 02197c14

Und ja, der swapper-Prozess ist dafür zuständig, die passenden Seiten aus dem Swap-Space in den realen Hauptspeicher zu laden, wenn diese benötigt werden (oder auch für die Auslagerung, was aber m.W. auch bei der 7530ax gar nicht wirklich genutzt wird) - dazu müssen sie aber erst einmal überhaupt im Kernel-Adress-Space existieren (sprich: die MMU muß dafür auch Einträge enthalten) und die o.g. Fehlermeldung ist i.d.R. ein Zeichen dafür, daß ein Kernel-Prozess auf eine NICHT VORHANDENE Adresse zugreifen will, weil ihm von irgendwo eine ungültige solche untergeschoben wurde und da vor dem Zugriffsversuch keine Prüfung erfolgte.

Schaut man sich die restlichen Register an, liegen praktisch alle Adressen irgendwo oberhalb von 0xA0000000 - und auch ohne die exakte Struktur des Speichers bei diesem Modell zu kennen, würde ich behaupten, daß alles unterhalb dieser Adressen nicht gemappt ist.

Wer stürzt da ab und was sagt uns der Backtrace? Es ist tatsächlich zweimal der swapper-Prozess - aber im Trace sieht man eben auch, daß es sich in beiden Fällen um eine IRQ-Behandlung und innerhalb dieser dann wieder um das Aktualisieren irgendwelcher Counter bzw. Statistiken handelt, was VOR dem Zugriff auf so eine ungültige Adresse erfolgen sollte.

Was ist denn da jeweils zuletzt aktiv gewesen? Nun, auf CPU 0 und 2 praktisch nichts (ob das an einer Affinität liegt oder nicht, weiß ich aber auch nicht), jedoch auf CPU 1 ist IN BEIDEN FÄLLEN der Prozess tdm_pcm sehr aktiv und ich bin bereit, ein kleines Vermögen darauf zu verwetten (ich hätte noch einige 7390 in der Kiste), daß das TDM in dessen Namen für "Time Division Multiplexing" steht und das ist zufällig genau das Verfahren, mit dem beim DECT die Timeslots genutzt/geteilt werden. Die anderen beiden CPUs "idlen" so vor sich hin - das Problem MUSS also auch auf CPU 1 liegen und eine (eigentlich nicht unterbrechbare, aber aufgrund massiver Probleme dann eben doch nicht richtig serialisierte/serialisierbare) Interrupt-Behandlung erscheint dann doch die logischste Erklärung. Und es ist eben auffällig, daß das alles auch auf dem einen Core geschieht und innerhalb des einen (Kernel-)Treibers/Prozesses, was aber beim IRQ-Handling auch wieder "normal" wäre, weil das nun mal nicht parallelisierbar ist (zumindest nicht bei derselben Quelle eines IRQ).

Auch ohne zu wissen, woran das letztlich liegt mit den sichtbaren Problemen ... daß es irgendetwas mit IRQ-Behandlung zu tun hat (und nichts mit einem echten Speicherproblem), läßt sich ja nun ziemlich sicher aus den Fehlerdaten ablesen - auch ohne die exakte Bedeutung jedes Registers dazu kennen zu müssen. Zieht man dann noch den Namen des Prozesses in Betracht und die Tatsache, daß parallel dazu dann DECT-Probleme "berichtet" werden, sollte das auch die Zuordnung des (angenommenen) TDM zum DECT (und nicht zu anderen Technologien, die ggf. auch noch mit TDM arbeiten) einigermaßen plausibel erscheinen lassen. Die Meldungen im Kernel-Log müssen ja auch erst mal ausgegeben werden - die Tatsache, daß die dann erst hinter dem ersten Zugriff mit ungültiger Adresse protokolliert werden, sagt auch nicht zwingend etwas über die tatsächliche "Reihenfolge" der Aktionen.

Die kprintf's können sogar ihrerseits die Ursache für die ungültigen Speicherzugriffe sein, wenn diese erst bei ihrer Bearbeitung auftreten (und die sind ja offensichtlich in einer "regulären" IRQ-Behandlung eher selten, wenn sie nur bei ungültigen DECT-Frames ausgegeben werden) - und innerhalb einer IRQ-Behandlung ist mitunter generell schlecht swappen. Auch wenn ich nicht weiß, ob AVM bei diesem Modell (des SoC) auch auf die eigene Implementierung eines Yield-Mechanismus setzt (es gibt für die 7530ax bei AVM jedenfalls keine Kernel-Quellen), mit dem eine schnellere Behandlung von Interrupts erfolgt, weil dabei keine vollständigen Kontextwechsel im Kernel vollzogen werden.

Der Preis, den man bei Verwendung dieser Art der IRQ-Behandlung zahlt, ist Speicherplatz - innerhalb so einer IRQ-Behandlung darf dann nämlich genau keine Paging-Exception auftreten ... und um das zu verhindern, weist AVM den eigenen Kernel-Modulen jeweils fixen Speicher zu, der gar nicht ausgelagert werden DARF. Dazu nutzt man u.a. die Modul-Tabellen in den avm_kernel_config-Strukturen (ich wette, die hat auch dieses Modell) - da steht dann jeweils drin, wieviel von diesem "non-paging memory" so ein LKM braucht und die Speicherzuordnungsfunktionen im Kernel hat AVM so abgeändert, daß da jeweils der richtige "Speichertyp" zugewiesen wird.

Wie gesagt - die Quellen fehlen zwar, aber bei anderen Modellen geht AVM genau so vor, wie ich es oben beschrieben habe ... und schaut man auf die Adressen, die bei den beiden Abstürzen ausgegeben wurden (die liegen ja nun vollkommen verquer im Adressraum), dann sinkt die Wahrscheinlichkeit, daß das "echter Speicher" an dieser Stelle ist (der dann auch nur von einem Hardware-Fehler betroffen sein kann), gegen Null. Denn von irgendwelchen Versuchen, gerade Daten vom User- in den Kernel-Space zu kopieren (oder umgekehrt), ist in keinem Backtrace etwas zu sehen - und der Kernel-Space (in dem sich dann auch der Kernel-Code nur bewegt, wenn er nicht über definierte Schnittstellen mit seiner Umgebung kommuniziert), liegt ja nicht irgendwo über den gesamten Adressraum des Prozessors verstreut.

Ich habe mir mal erlaubt, die Kernel-Panics der beiden Abstürze hier zu editieren und diesen ganzen Müll mit den Leerzeilen zu entfernen - vielleicht kann man ja in "kondensierter Form" besser erkennen/nachvollziehen, wovon ich oben überhaupt schreibe.

EDIT: Was ich jetzt erst gesehen habe (weil's ganz am Ende steht) ist das "Fazit" für dieses Problem (in beiden Logs):

Kernel panic - not syncing: Fatal exception in interrupt

... schöner kann man fast nicht ausdrücken, daß im IRQ-Handling selbst ein (weiteres) Problem aufgetreten ist.

EDIT2:
Im zweiten Log sieht man gar nichts davon
DAS kann ich nun wieder gar nicht nachvollziehen:

peh@vidar:~> grep -ri DECT Downloads/panic1_condensed.txt
<4>[ 2005.590835][1]Modules linked in: eth_oam(P) nf_conntrack_ipv6 nf_defrag_ipv6 xt_connbytes ip6table_filter ulpcmlink(P) krtp(PO) userman_mod(PO) bcm_usb ohci_platform ohci_hcd ehci_platform ehci_hcd sch_fq_codel sch_llq nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_SKIPLOG xt_TCPMSS nfnetlink ip6table_mangle ip6_tables iptable_mangle iptable_filter ip_tables xt_blog xt_multiport xt_mark xt_u32 xt_flowlabel xt_mac_extend xt_mac xt_DSCP xt_dscp adsldd(PO) wl(PO) igs(PO) emf(PO) hnd(O) cfg80211 kdsldmod(PO) dect_io(P) avm_dect(P) capi_codec(P) cchardev(PO) cprocfsmod(PO) otp(P) bcm_thermal pwrmngtd(P) usbcore usb_common bcmmcast bcm_enet bcmxtmcfg(P) bcmxtmrtdrv archer(P) isdn_fbox_fon5(P) cmdlist(P) pktflow(P) bcm_license(P) pcmlink(P) bcm_ingqos(P) chipinfo(P) bcmvlan(P) rtc_avm bcmlibs(P) Piglet_noemif(P) bcm_pcie_hcd wlcsm(P) led_module(PO)
<3>[ 2005.769840][F1][DECTDRV_ERR] pcm count 105 != 101
<3>[ 2005.775790][F1][DECTDRV_ERR] pcm count 0 != 107
peh@vidar:~> grep -ri DECT Downloads/panic2_condensed.txt
<4>[ 2586.212046][1]Modules linked in: kspeedtest(O) eth_oam(P) nf_conntrack_ipv6 nf_defrag_ipv6 xt_connbytes ip6table_filter ulpcmlink(P) krtp(PO) bcm_usb userman_mod(PO) ohci_platform ohci_hcd ehci_platform ehci_hcd sch_fq_codel sch_llq nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_state nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack xt_SKIPLOG xt_TCPMSS nfnetlink ip6table_mangle ip6_tables iptable_mangle iptable_filter ip_tables xt_blog xt_multiport xt_mark xt_u32 xt_flowlabel xt_mac_extend xt_mac xt_DSCP xt_dscp adsldd(PO) wl(PO) igs(PO) emf(PO) hnd(O) cfg80211 kdsldmod(PO) dect_io(P) avm_dect(P) capi_codec(P) cchardev(PO) cprocfsmod(PO) otp(P) bcm_thermal pwrmngtd(P) usbcore usb_common bcmmcast bcm_enet bcmxtmcfg(P) bcmxtmrtdrv archer(P) isdn_fbox_fon5(P) cmdlist(P) pktflow(P) bcm_license(P) bcm_ingqos(P) pcmlink(P) chipinfo(P) bcmvlan(P) bcmlibs(P) rtc_avm Piglet_noemif(P) bcm_pcie_hcd wlcsm(P) led_module(PO)
<3>[ 2586.407982][F1][DECTDRV_ERR] pcm count 0 != 116
<3>[ 2586.419985][F1][DECTDRV_ERR] PCM frame 424c NOK b5 00 c1 00 c3 00 c6 00 c4 00 c3 00 c3 00 b6 00 ab 00 a6 00 a1 00 a2 00 b2 00 ba 00 bf 00 c3 00 c2 00 c3 00 be 00 bc 00 c0 00 bc 00 b8 00 bb 00 b0 00 a3 00 a2 00 9e 00 a3 00 a0 00 a8 00 b4 00
<3>[ 2586.419990][F1][DECTDRV_ERR] checksum error(len=185): calculated: 0x424c != 0xbb00 (received)
<3>[ 2586.423979][F1][pcmlink]error: workarround: strange dect-ctrl-slot-value fefe -> resync
<3>[ 2586.423985][F1][DECTDRV_ERR] pcm count 0 != 1
<3>[ 2586.435972][F1][DECTDRV_ERR] PCM frame 3ab2 NOK a1 00 9f 00 a4 00 a4 00 a6 00 b2 00 c0 00 c5 00 c6 00 c5 00 c6 00 c3 00 c2 00 bf 00 b9 00 b3 00 ae 00 a0 00 9e 00 9b 00 a5 00 ad 00 bf 00 bf 00 c3 00 c4 00 c5 00 c4 00 bf 00 c2 00 b8 00 aa 00
<3>[ 2586.435976][F1][DECTDRV_ERR] checksum error(len=165): calculated: 0x3ab2 != 0x9b00 (received)
<3>[ 2586.435979][F1][DECTDRV_ERR] pcm count 0 != 1
<3>[ 2586.447971][F1][DECTDRV_ERR] PCM frame 3ab2 NOK a1 00 9f 00 a4 00 a4 00 a6 00 b2 00 c0 00 c5 00 c6 00 c5 00 c6 00 c3 00 c2 00 bf 00 b9 00 b3 00 ae 00 a0 00 9e 00 9b 00 a5 00 ad 00 bf 00 bf 00 c3 00 c4 00 c5 00 c4 00 bf 00 c2 00 b8 00 aa 00
<3>[ 2586.447975][F1][DECTDRV_ERR] checksum error(len=165): calculated: 0x3ab2 != 0x9b00 (received)
<3>[ 2586.603918][F1][DECTDRV_ERR] pcm count 0 != 1
<3>[ 2586.615910][F1][DECTDRV_ERR] PCM frame 3ab2 NOK a1 00 9f 00 a4 00 a4 00 a6 00 b2 00 c0 00 c5 00 c6 00 c5 00 c6 00 c3 00 c2 00 bf 00 b9 00 b3 00 ae 00 a0 00 9e 00 9b 00 a5 00 ad 00 bf 00 bf 00 c3 00 c4 00 c5 00 c4 00 bf 00 c2 00 b8 00 aa 00
<3>[ 2586.615914][F1][DECTDRV_ERR] checksum error(len=165): calculated: 0x3ab2 != 0x9b00 (received)
<3>[ 2586.615917][F1][DECTDRV_ERR] pcm count 0 != 1
<3>[ 2586.627922][F1][DECTDRV_ERR] PCM frame 6961 NOK a1 00 9f 00 a4 00 a4 00 a6 00 b2 00 c0 00 c5 00 c6 00 c5 00 c6 00 c3 00 c2 00 bf 00 b9 00 b3 00 ae 00 a0 00 9e 00 9b 00 a5 00 ad 00 bf 00 bf 00 c3 00 c4 00 c5 00 c4 00 bf 00 c2 00 b8 00 aa 00
<3>[ 2586.627926][F1][DECTDRV_ERR] checksum error(len=165): calculated: 0x6961 != 0xffff (received)
peh@vidar:~>

... ich sehe da in beiden Protokollen eine ausreichende Menge an Fehlermeldungen vom DECTDRV, die überdies im Text auch noch ein PCM (sicherlich für "Pulse Code Modulation") enthalten, was dann den zweiten Teil des "sprechenden Namens" von tdm_pcm (siehe Log) bildet.

PS: Ich habe mir beim Kopieren aus dem zweiten Beitrag in seinen Vorgänger die Freiheit genommen, in der Ausgabe für panic1_condensed.txt die Zeilen zu entfernen, die erkennbar lange vor dem Timestamp zum Fehlerzeitpunkt (Sekunde 2005 im Log) lagen - das macht den Punkt, den ich eigentlich meinte, deutlicher.

 

[frank_m24]

Bei dir sind die Namen vertauscht, panic1 ist das später gepostete Log und umgekehrt.

... ich sehe da in beiden Protokollen eine ausreichende Menge an Fehlermeldungen vom DECTDRV, die überdies im Text auch noch ein PCM (sicherlich für "Pulse Code Modulation") enthalten, was dann den zweiten Teil des "sprechenden Namens" von tdm_pcm (siehe Log) bildet.

Ich sehe die im zweiten Log (panic1...) immer noch nicht ... zwei vereinsamte "pcm count x != y" und das wars, aber definitiv keine Checksum Fehler. Die Meldungen aus der Initialisierungsphase können wir wohl ignorieren.

Dennoch waren die PCM Fehler der Grund, warum ich nach einem laufenden Telefonat gefragt habe.

 

[PeterPawn]

Wie ich schon schrieb - üblicherweise sollte innerhalb einer IRQ-Behandlung GAR KEIN kprintf auftauchen - zumindest nicht, falls AVM auch hier auf das eigene Yield() setzt. Denn die Ausgabe einer solchen Fehlermeldung ist ja nicht damit getan, daß da irgendwo der Code für dieses kprintf aufgerufen wird und der kommt dann nach zwei, drei, zwanzig (Assembler-)Befehlen wieder zurück. Um so eine Meldung zu komplettieren und in den Buffer für das Log zu schreiben, sind deutlich mehr Aktionen erforderlich - angefangen bei der "severity" und dem Zeitstempel der Meldung (die ersten beiden Felder) bis hin zur CPU-Nummer (das dürfte das dritte Feld sein) und erst danach kommt dann die eigentliche Nachricht, wobei auch hier die Umwandlung der Argumente entsprechend der Format-Maske für die Nachricht, noch vieles weitere nach sich zieht (bzw. zumindest ziehen kann).

Wenn es "normal" wäre, daß innerhalb so einer IRQ-Behandlung STÄNDIG solche Meldungen ausgegeben werden, dann wäre das Kernel-Log wohl deutlich größer - das ist also schon per se eine Ausnahmesituation, wenn so etwas überhaupt auftritt. Und zur "nicht zwingenden Reihenfolge" hatte ich auch schon etwas geschrieben - wenn so eine Fehlermeldung (und sei sie so simpel wie die zwei mit dem Mismatch bei der Paket-Nummer - so interpretiere ich zumindest die Meldung) eine Paging-Exception auslöst und diese dann wieder einen Backtrace, dann ist auch zu erwarten, daß die eigentliche Meldung erst NACH dem Backtrace (zumindest nach dem Teil, der noch "nicht unterbrechbar" ist) im Log auftaucht.

Auch verstehe ich nicht so ganz, warum Du unbedingt nach einem DECT-Telefonat fragst - die übertragenen Frames können ja auch problemlos reine "Datenpakete" von einem der drei HKRs sein ... und was da an DECT-Geräten angemeldet ist bei ihm, steht in diesem Thread weiter vorne. Die Tatsache, daß da gerade niemand telefonierte, sagt ja noch nichts darüber aus, ob da gerade PCM-Frames gesendet oder empfangen werden.

EDIT: Die Dateinamen meiner beiden Anhänge sollen auch keine zeitliche Reihenfolge festlegen ... das machen schon die jeweiligen UPTIME-Angaben in den Daten selbst (ganz am Anfang), solange eine gültige Uhrzeit vorlag - was hier ja auch nicht das Problem sein sollte, weil es ja keine Schleife mit Reboots ist, die jegliche Netzwerk-Aktivität verhindert.

 

[frank_m24]

Und zur "nicht zwingenden Reihenfolge" hatte ich auch schon etwas geschrieben - wenn so eine Fehlermeldung (und sei sie so simpel wie die zwei mit dem Mismatch bei der Paket-Nummer - so interpretiere ich zumindest die Meldung) eine Paging-Exception auslöst und diese dann wieder einen Backtrace, dann ist auch zu erwarten, daß die eigentliche Meldung erst NACH dem Backtrace (zumindest nach dem Teil, der noch "nicht unterbrechbar" ist) im Log auftaucht.

Kann sein. Kann auch anders sein.

Die Tatsache, daß da gerade niemand telefonierte, sagt ja noch nichts darüber aus, ob da gerade PCM-Frames gesendet oder empfangen werden.

Aber ein Telefonat erhöht die Wahrscheinlichkeit.

 

[PeterPawn]

Kann sein. Kann auch anders sein.

Das stimmt - vielleicht sollte er die Box ja auch mal drehen?

Ich kann darin leider keine "Gegenargumentation" erkennen - aber auch ich habe ja deutlich gemacht, daß ich nur "spekuliere". Allerdings eben mit Begründung, was ich da heraus zu lesen meine ... DAS finde ich irgendwie nicht bei Dir (zumindest nicht im zitierten Text).

Aber ein Telefonat erhöht die Wahrscheinlichkeit.

Wofür? DASS Pakete ausgetauscht werden? Und wie weit geht das dann über die Tatsache hinaus, daß beide Male zum Fehlerzeitpunkt im Kernel-Log Einträge des DECT-Treibers auftauchen? Oder siehst Du da noch irgendwelche anderen Treiber, die in beiden Protokollen zeitnah zum Absturz ein Problem gemeldet haben? Wo könnte man denn Fehlermeldungen finden, welche die These eines "Speicherproblems" stützen?

 

[frank_m24]

DAS finde ich irgendwie nicht bei Dir (zumindest nicht im zitierten Text).

Ich hatte ja erwähnt, dass ich es durchaus für denkbar halte, dass die DECT Probleme eine Folge des Crashes sind, und nicht die Ursache. Ich habs in den letzten 25 Jahren oft genug erlebt, dass die erste offensichtliche Fehlermeldung nicht zwangsläufig auch der Schlüssel zur Lösung war. Wir können nach dem Crash kaum davon ausgehen, dass das System noch in der Lage ist, die Schnittstellen ordnungsgemäß zu bedienen. Gerade im Umfeld von Kernel OOPSes können verschiedene Auswirkungen auf andere Prozesse zu sehen sein, auch wenn sie nicht unmittelbar zum Freeze oder Reboot führen.

Wofür? DASS Pakete ausgetauscht werden?

Genau. Ich weiß nicht, ob bei AVM das PCM zwangsläufig auf Audio-Daten hindeutet. Möglicherweise heißen die Prozesse aus historischen Gründen "PCM" und behandeln inzwischen auch die Smart Home Daten, das kann aber auch anders sein. Bei einem Telefonat hingegen ist die Wahrscheinlichkeit sehr hoch, dass tatsächlich PCM involviert ist.
Und auch das lehrt die Erfahrung: Ein Telefonat wird sehr wahrscheinlich die Anzahl der zu übertragenden Pakete im DECT Zweig deutlich erhöhen, und mehr Last erhöht häufig auch die Wahrscheinlichkeit eines Fehlereintritts, wenn da irgendwo ein Problem lauert.

Und um das alles weiter einzugrenzen und den Einfluss von DECT zu verifizieren, hab ich nach dem Telefonat und dem Deaktivieren von DECT gefragt.

 

[theGamer93]

Ich telefoniere nicht wirklich mit den Fritz!Phones. Ich habe die nur für den Notfall bzw als Fernbedienung für die Thermostate. Auf jeden Fall habe ich zum Zeitpunkt des Crashs nicht telefoniert. Es gab ja um 4:20 noch einen Crash, da wurde nichtmal das Internet wirklich genutzt, nur das was IoT halt so braucht, kurz mal nen Ping o.Ä.

 

[sonyKatze]

DECT ist immer aktiv, wenn es an ist; man muss es also nicht aktiv nutzen, damit es aktiv ist. Aber das versuchte Peter im Post #35 bereits zu erklären. Mal anders: theGamer93 hast Du mal zum Test die DECT-Basis in Deiner FRITZ!Box komplett abgeschaltet?