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

theGamer93

Neuer User
Mitglied seit
16 Sep 2007
Beiträge
35
Punkte für Reaktionen
0
Punkte
6
Moin,
ich hab hier eine 7530 AX mit 1&1 Branding, welche ständig abstürzt. Ich hatte bis 30.11. einen Vodafone Kabel Anschluss, während mein DSL-Anschluss schon lief. Die DSL-Box lief testweise rund einen Monat problemlos und ohne Abstürze. Jetzt hab ich den Wifi-Namen der DSL-Box (7530AX) geändert + LAN-Kabel umgesteckt von der Kabel-Fritzbox und jetzt stürzt die Fritzbox sporadisch ab. Weil ich etwas Geld sparen wollte, habe ich ne gebrauchte 7530AX gekauft und jetzt wohl einen Griff ins Klo gemacht. Lieferschein gibts nicht und damit wohl auch keine Garantie. Alles was sonst dabei ist hab ich aber. Also Anleitung und sogar den Startcode inkl. Zugangsdaten... Ganz schön fahrlässig.

Ich wollte jetzt das Crash-Log anschauen um herauszufinden warum die Box überhaupt abstürzt aber dafür brauch ich wohl Telnet-Zugang richtig? und für Telnet muss ich mittels modfs ne modifizierte Firmware aufspielen korrekt? :|
Gibt es da ne simple Methode für? Ich will nur die Crashlogs heraussuchen, eventuell ist es nur ein Dienst der die Box zum abstürzen bringt.

Ein Reset hat übrigens auch nichts gebracht, das Netzteil der Kabel-Fritzbox hab ich auch probiert. Das kann 3,5A statt der geforderten 1,5A liefern und die Box stürzt trotzdem ab. Hat jemand hier noch Idee?

Die Kabel-Box lief immer problemlos, daher schließe ich Probleme mit Netzwerkgeräten erstmal aus.
 
Ich wollte jetzt das Crash-Log anschauen um herauszufinden warum die Box überhaupt abstürzt aber dafür brauch ich wohl Telnet-Zugang richtig?
Das ist in den Support Dateien zu finden. Erstelle beide - die einfache und die erweiterte. Telnet braucht man da nicht unbedingt.
 
Was genau heißt denn "stürzt ab"? Friert sie ein? Rebotet sie? Verliert sie den Internetzugang?

Für den Anfang wäre auch das reguläre Fehlerlog der Box hilfreich, bevor wir uns um die anderen Logs kümmern (an die man auch ohne telnet herankommen kann).
 
Die Fritzbox startet komplett neu. Die Diagnose-Datei findet man unter "Internetzugang, AVM-Dienste, Diagnosezusammenfassung ansehen" oder? Ist das schon die komplette Log oder gibt es da noch ausführlichere Daten?

edit: Hab es gefunden. Inhalt - Support und da die erweiterten Daten.

edit2: Hmm libbcm.so verursacht wohl den Crash. Das klingt doof. Ist das schon ein Indiz für einen Hardwarefehler?

Code:
##### BEGIN SECTION CRASHLOG /proc/avm/log_sd
==========

BEGIN SECTION '/proc/avm/log_sd/crash'
----------
1970-01-01 01:00:36(1) [Segmentation fault] nvram([2447]) CRASHED at 0+0xb6553c34 (/lib/libbcm_util.so at 00000c34) accessing 9f827c43
SIGNO 11 ERRNO 0 CODE 1
UPTIME: 36
Version: 07.27
pc : b6553c34  lr : b67b14bc  psr: a0000010
sp : be5c5cb0  ip : b673dec0  fp : be5c5da4
r10: b67d1908  r9 : 00000001  r8 : be5c5d1c
r7 : b6565e60  r6 : 00000021  r5 : 00000019  r4 : b67d0ac8
r3 : e92d4007  r2 : 00000074  r1 : b6565eb0  r0 : b653f004
tno: 0000000e  ec : 00000005  om : 00000000  fa : 9f827c43
FA 9f827c43
PC b6553c34 0+0xb6553c34 (/lib/libbcm_util.so at 00000c34)
PC Code: e59f3028 e79f0003 ebffff6e <ebffffbe> e59f301c e3a02001 e08f3003 e5c32000 e8bd8010
LR b67b14bc 0+0xb67b14bc (/lib/ld-linux.so.3 at 000104bc)
LR Code: e0837109 e5373004 e12fff33 <e2599001> 1afffffb e5943054 e3530000 0a000003 e5932004
[bt]  b6553c34 [b6553c18] <0+0xb6553c18>+0x1c (/lib/libbcm_util.so at 00000c18/0xc34)
                        Code: e59f3028 e79f0003 ebffff6e <ebffffbe> e59f301c e3a02001 e08f3003 e5c32000 e8bd8010
[bt]  b67b14b8 [b67b1274] <0+0xb67b1274>+0x244 (/lib/ld-linux.so.3 at 00010274/0x104b8)
                        Code: 0a000004 e0837109 e5373004 <e12fff33> e2599001 1afffffb e5943054 e3530000 0a000003
[bt]  b67d0ac4 b67ccac4+0x4000 (?)
                        Code: 5f6d6362 6c697475 006f732e <00000000> b6553000 b67d0ab0 b6565e68 b67cd000 b67d0818
Signal Segmentation fault in crashdump: in do_arm_backtrace (2)
1970-01-01 01:00:36(2) [Segmentation fault] nvram([2447]) CRASHED at 0+0xb6742000 (/lib/libbacktrace.so.1 at 00002000) accessing fffffffc
SIGNO 11 ERRNO 0 CODE 1
pc : b6742000  lr : 00000001  psr: 20000010
sp : b675a2a8  ip : b67d24c4  fp : ffffc000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : fffffffc  r6 : 00000000  r5 : b67cc018  r4 : fffffffc
r3 : fffffffc  r2 : 00000001  r1 : fffffffc  r0 : e92d0000
tno: 0000000e  ec : 00000017  om : 00000000  fa : fffffffc
FA fffffffc
PC b6742000 0+0xb6742000 (/lib/libbacktrace.so.1 at 00002000)
PC Code: e58d202c 0a0000ab e1a01007 <e4115004> e1a02825 e1a02802 e1520000 1a000010 e3150b12
lr 00000001
LR Code: <illegal function pointer>
[bt] abort due to double fault
[bt] finished.

1970-01-01 01:00:36(1) [Segmentation fault] ctlmgr([2412]) CRASHED at 0+0xb5c1cbdc (/lib/libc.so.6 at 00069bdc) accessing 6b914cb0
SIGNO 11 ERRNO 0 CODE 1
UPTIME: 36
Version: 07.27
Watchdog triggered 0 seconds ago
No bugmsg
pc : b5c1cbdc  lr : b5c0de30  psr: 00000010
sp : be641398  ip : b61f0bfc  fp : be6435fc
r10: b6701908  r9 : 00000000  r8 : b513bb08
r7 : b6701900  r6 : 000d8258  r5 : 00000001  r4 : b5125200
r3 : 6b914cb0  r2 : fbad2489  r1 : 0000000a  r0 : b5125200
tno: 0000000e  ec : 00000005  om : 00000000  fa : 6b914cb0
FA 6b914cb0
PC b5c1cbdc 0+0xb5c1cbdc (/lib/libc.so.6 at 00069bdc)
PC Code: e08f3003 e5935000 e08f6006 <e3550000> 1a000070 e59f32c4 e58d500c e08f3003 e58d3008
LR b5c0de30 fclose+0x130 (/lib/libc.so.6 at 0005ae30)
LR Code: e28dd00c e8bd80f0 eb003c2b <e5942000> e3120902 1a000016 e5940048 ee1d5f70 e2455d13
[bt]  b5c1cbdc [b5c1cbc0] <0+0xb5c1cbc0>+0x1c (/lib/libc.so.6 at 00069bc0/0x69bdc)
                        Code: e08f3003 e5935000 e08f6006 <e3550000> 1a000070 e59f32c4 e58d500c e08f3003 e58d3008
[bt]  b5c0de2c [b5c0dd04] <fclose+0x4>+0x128 (/lib/libc.so.6 at 0005ad04/0x5ae2c)
                        Code: e1a00005 e28dd00c e8bd80f0 <eb003c2b> e5942000 e3120902 1a000016 e5940048 ee1d5f70
[bt]  b61cac50 [b61cab7c] <urlader_getenv+0x8>+0xd4 (/lib/libavmcsock.so.2 at 0005bb7c/0x5bc50)
                        Code: e3500000 15c09000 e1a00006 <ebfee0ac> e1a00004 e28d3a02 e2833004 e5932000 e5973000
[bt]  b5128398 [b5128248] <0+0xb5128248>+0x150 (/lib/libbroadbandcfg.so.1 at 00002248/0x2398)
                        Code: e5c13000 e08f0000 e2800080 <ebfffdc7> e2509000 0a000013 ebfffd9d e1a01009 e1a02000
[bt]  b5129424 [b51293e8] <0+0xb51293e8>+0x3c (/lib/libbroadbandcfg.so.1 at 000033e8/0x3424)
                        Code: 0a00007a e1a0000d e59f8238 <e12fff34> e59f1234 e1a09000 e3002201 e59d0000 e08f8008
[bt]  b5127cbc [b5127c24] <0+0xb5127c24>+0x98 (/lib/libbroadbandcfg.so.1 at 00001c24/0x1cbc)
                        Code: e59f0068 e08f1001 e08f0000 <eb0005c8> e3500000 a8bd8070 e59f3054 e7944003 e5943000
[bt]  b66e1080 [b66e0fdc] <0+0xb66e0fdc>+0xa4 (/lib/ld-linux.so.3 at 0000ffdc/0x10080)
                        Code: e1a02009 e1a01008 e1a00007 <e12fff35> e1560004 1afffff8 e8bd87f0 e5903084 e3530000
[bt]  b66e11dc [b66e111c] <0+0xb66e111c>+0xc0 (/lib/ld-linux.so.3 at 0001011c/0x101dc)
                        Code: e1a03009 e1a02008 e1a01007 <ebffff7d> e3540000 e2444001 1afffff2 e8bd87f0 e5d0c198
[bt]  b66e50cc [b66e4e20] <0+0xb66e4e20>+0x2ac (/lib/ld-linux.so.3 at 00013e20/0x140cc)
                        Code: e591301c e5912018 e5911014 <ebfff011> e51b3028 e3130c01 1a000093 e59f34e0 e08f3003
Signal Segmentation fault in crashdump: in do_arm_backtrace (2)
1970-01-01 01:00:36(2) [Segmentation fault] ctlmgr([2412]) CRASHED at 0+0xb6184770 (/lib/libavmcsock.so.2 at 00015770) accessing fffffff8
SIGNO 11 ERRNO 0 CODE 1
pc : b6184770  lr : 00000001  psr: 20000010
sp : b61f90d8  ip : b67024c4  fp : ffffbffc
r10: 00000000  r9 : 00000000  r8 : fffffffc
r7 : fffffff8  r6 : 00000000  r5 : 00000008  r4 : fffffff8
r3 : fffffff8  r2 : 00000001  r1 : fffffff8  r0 : e92d0000
tno: 0000000e  ec : 00000017  om : 00000000  fa : fffffff8
FA fffffff8
PC b6184770 0+0xb6184770 (/lib/libavmcsock.so.2 at 00015770)
PC Code: e58d202c 0a0000ab e1a01007 <e4115004> e1a02825 e1a02802 e1520000 1a000010 e3150b12
lr 00000001
LR Code: <illegal function pointer>
[bt] abort due to double fault
[bt] finished.
-----
crashreport: read crash-variable '[0]f51b3592,61acb913,1[1]0,0,0[2]15e797ef,615f32fb,1[3]0,0,0'
crashreport: old parsed checksum[2].cs = 15e797ef new_sum=15e797ef (new_len=5602)
crashreport: crash-variable set to '[0]f51b3592,61acb913,1[1]0,0,0[2]15e797ef,615f32fb,3[3]0,0,0'
(first) sent on: Thu Oct 07 17:48:43 2021 UTC by crash report
----------
 
Zuletzt bearbeitet:
Ist das schon ein Indiz für einen Hardwarefehler?
Nein. Die Frage ist ja: Warum treten die Reboots erst auf, seit dem du das Kabel eingesteckt hast? Da halte ich es für wesentlich wahrscheinlicher, dass die Fehlerursache damit zusammenhängt. Ich könnte mir Probleme in der Elektro-Installation mit Potentialausgleichsströmen gut als Ursache vorstellen.

Die Frage wäre darüber hinaus noch: Was hast du sonst noch alles geändert außer Kabel und WLAN SSID? VoIP, Filter, Dyndns, ... Wenn der DSL Zugang zum Haupt-Interzugang wurde, dann hängt da ja noch mehr dran, als nur ein Kabel und ein paar WLAN Geräte.
 
Ich hatte die ganze Zeit eine 6591 im Betrieb und habe diese zu Vertragsende bei Vodafone, außer Betrieb genommen. Die Fritzbox 7530AX habe ich Testweise aufgebaut gehabt und quasi nur eine Zahl in der SSID geändert. So konnte ich mich immer mal wieder auf der Fritzbox anmelden und da gab es halt keine Abstürze.

Was sich seitdem geändert hat:

Repeater 600 + Repeater 1200 angemeldet und gepairt, 3x Fritz DECT 301 Thermostate gekoppelt, 2x Fritz Phone C5 gekoppelt, drei Geräte per LAN angeschlossen. Ich mein klar das sind schon ein paar Geräte, aber das sollte die Box ja alles ab können. Hat ja vorher mit der 6591 auch problemlos funktioniert. Außer wenn Stromausfall war oder wenn Vodafone mal Settings oder ne Firmware aufgespielt hat, war die Box nie offline. Die 7530AX hat sich heute um 11:50 und dann kurz nach dem ersten Post um 14:00 neu gestartet.

Habe die Box mal vorsichtig zerlegt und auch das Hitzeschild vorsichtig demontiert. Soweit sah alles okay aus, das Hitzeschild war relativ warm aber nicht heiß. Habe beim Zusammenbau mal alles vorsichtig angedrückt, sodass da wirklich alles gut sitzt. Bisher ist Sie seit 15:01 mit dem Internet verbunden.
 
Da würde ich jetzt nicht allzu viel auf das Crash-Log geben ... wenn die Angaben stimmen, wurde der Bericht dazu erstmals schon am 07.10.2021 (letzte Zeile im "Auszug") an AVM gesendet. Es ist bei der AVM-Firmware so, daß die Daten im nicht-flüchtigen Speicher abgelegt und dann i.d.R. gelöscht werden, sowie sie (z.B. im Rahmen der Support-Daten) ausgelesen wurden. Hat bisher niemand die Daten ausgelesen, können die problemlos von Abstürzen stammen, die sehr viel früher stattgefunden haben.

Das jetzt erfolgte Auslesen sollte die Daten nun ja gelöscht haben und so sollte man erst mal abwarten, was nach dem NÄCHSTEN Absturz am Ende in der Support-Datei steht. Denn das Fehlerbild im Stack-Trace darüber paßt auch nicht zur Beschreibung "sporadisch abstürzt" - der oben dokumentierte Fehler trat in Sekunde 36 nach dem Start des OS (bzw. des internen Zeitgebers) auf, als noch gar keine korrekte Uhrzeit gesetzt war. Bei diesem Fehler (der vermutlich auch einen Neustart der Box nach sich zog, weil der ctlmgr davon wohl auch betroffen war und der ist über einen Watchdog abgesichert) hätte die Box praktisch nur für Sekunden (wenn überhaupt) das GUI bereit gehalten - das paßt auch nicht zur Tatsache, daß ja offenbar die Support-Daten ausgelesen werden können.



Also ... alles bisherige in der Support-Datei vergessen und auf den nächsten Absturz hoffen - ich weiß nicht sicher, ob bei den BCM-Boxen (m.W. sind es nur drei bisher bei AVM) keine weiteren Abstürze aufgezeichnet werden, solange vorhergehende nicht ausgelesen wurden ... aber komisch ist es schon, wenn die Box "gefühlt" seitdem schon mehrfach abgestürzt ist (es gäbe für Kernel-Panic und User-Space-Crashes getrennte Protokolle), aber das oben gezeigte Crash-Log im User-Space dabei die einzige Aufzeichnung ist. Da war nicht zufällig doch noch ein Log einer "kernel panic" in derselben Support-Datei enthalten? "Stille" Abstürze sind eigentlich eher selten bei AVM, weil es extra einen Exception-Handler im Kernel gibt, der noch sicherstellen soll, daß auch in solchen Fällen Daten (zum Problem) so gesichert werden, daß sie hinterher auch ausgelesen werden können.
 
Laut crashlog FW 7.27? Ich würde Mal ein FW - Update anstoßen auf 7.29 oder Beta. Der Log ohne Uhrzeit deutet auf fehlende I- Net-Verbindung hin, respektive NTP im lokalen Netz. Falls die Uptime nur 36 Sekunden, kann eine DSL- Verbindung inkl. Training noch nicht vorhanden sein, wobei dann halt auch Datum+Uhrzeit fehlt.
Ein FW- Update ggfs. via Datei und/ oder ein entsprechend sauberes Recovery wäre mein unmassgeblicher Vorschlag. Der Log sieht eher wie ein Speicherproblem aus.
LG
 
@Micha0815 Das deckt sich mit der Aussage von @PeterPawn . Das Supportlog was ich da gelesen habe, war von Oktober und damit alt. Die Box ist schon länger auf 7.29. Ich habe aber tatsächlich vor dem Crash heute mittag schon das Supportfile gezogen und dann nach dem Reboot um 15:01 nochmal eins geladen und da fehlt der Crashlog komplett.





Aber ich habe eine panic-File gefunden und beschnitten um Redundante Zeilen. Kann das volle Support-File gerne bereitstellen. Ist das problematisch oder kann ich das öffentlich hochladen?



Code:
UPTIME: 2585



(0 d 0 h 43 min 5 s - panic on Sun Dec 05 :45:40 2021 UTC )



Irregular Reboots: SUM(6) - NMI(3) KCRASH(3) (since last regular reboot/power-cut)



HW: 256.1



FW: 07.29



Bootloader: 1.11177



PANIC LOG VERSION 3.0



<1>[ 2586.180475][1]Unable to handle kernel paging request at virtual address 02197c14



<1>[ 2586.187889][1]pgd = c0004000



<1>[ 2586.190767][1][02197c14] *pgd=00000000



<0>[ 2586.194351][1]Internal error: Oops: 5 [#1] PREEMPT SMP ARM



<3>[ 2586.199853][1]set_reboot_status: Soft-Reboot(KCRASH)  - NMI(3) KCRASH(3)SUM(6)UP(2585)UTC(1638711940)FW(07.29)HW(256)HWS(1)BV(1.11177)



<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)



<0>[ 2586.293832][1]Process swapper/1 (pid: 0, stack limit = 0xdec3e210)



<3>[ 2586.300012][1]



<3>[ 2586.301673][1]CPU: 1 Pid: 0, comm:            swapper/1



<3>[ 2586.306894][1]       Tainted: P           O     (4.1.52 #1)



<4>[ 2586.312470][1]PC is at rcu_check_callbacks+0x1f4/0x8e8



<4>[ 2586.317606][1]LR is at update_process_times+0x38/0x64



<3>[ 2586.322653][1]pc :[<c006a0b4>] lr :[<c006c750>] psr: 80000193



<3>[ 2586.322653][1]sp :  dec3fe60   ip :  00000001   fp : c06797c0



<3>[ 2586.334125][1]r10:  c06ad95c   r9 :  00000001   r8 : df012080



<3>[ 2586.339865][1]r7 :  00000011   r6 : df7d0300    r5 : 00000000 r4 : 00000001



<3>[ 2586.346821][1]r3 :  e3043c14   r2 : 1f154000    r1 : dec3fe60 r0 : 00000001



<3>[ 2586.353778][1]Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel



<3>[ 2586.361254][1]Control: 10c5387d  Table: 126a004a  DAC: 00000015



<3>[ 2586.367234][1]Classified pointer on registers:



<3>[ 2586.371672][1]r1 : dec3fe60 [stack(swapper/1): dec3e000+0x1e60]



<3>[ 2586.377629][1]r3 : e3043c14 [ioremap : size:32509952 start:e2000000+0x1043c14 alloced by:0xc02fda14 platram_probe+0xc4/0x2a0]



<3>[ 2586.388981][1]r6 : df7d0300 [page: type:reserved]



<3>[ 2586.393727][1]r8 : df012080 [slab: type:kmalloc-64 size:128 start:0xdf012080+0x0 allocated by:0xc0061548 request_percpu_irq+0x50/0xf0]



<3>[ 2586.406027][1]Backtrace:



<3>[ 2586.407982][F1][DECTDRV_ERR] pcm count 0 != 116



<3>[ 2586.413101][1]1ec4: [<c006a0b4>] (0xc006a0b4 rcu_check_callbacks+0x1f4/0x8e8)



<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)





(... Zeile wiederholte sich noch c.a. 10-11 mal )



<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)



<3>[ 2587.036738][1]1ed4: [<c006c750>] (0xc006c750 update_process_times+0x38/0x64)



<3>[ 2587.043793][1]1efc: [<c0079f8c>] (0xc0079f8c tick_handle_periodic+0x28/0x88)



<3>[ 2587.050847][1]1f04: [<c0334c60>] (0xc0334c60 arch_timer_handler_phys+0x28/0x30)



<3>[ 2587.058159][1]1f1c: [<c0062cec>] (0xc0062cec handle_percpu_devid_irq+0x6c/0x84)



<3>[ 2587.065470][1]1f24: [<c005ed4c>] (0xc005ed4c generic_handle_irq+0x2c/0x3c)



<3>[ 2587.072352][1]1f3c: [<c005efe8>] (0xc005efe8 __handle_domain_irq+0x5c/0xb4)



<3>[ 2587.079323][1]1f5c: [<c000946c>] (0xc000946c gic_handle_irq+0x54/0x118)



<4>[ 2587.085938][1]Exception stack(0xdec3ff60 to 0xdec3ffa8)



<4>[ 2587.091167][1]ff60: dec3ffa8 00000018 0323f4e1 0000025a 0323f4e1 0000025a 00000001 df7ccec0



<4>[ 2587.099516][1]ff80: 0315b345 0000025a c06ad95c c06797c0 13ffffc6 dec3ffa8 fffffff8 c0332be4



<4>[ 2587.107862][1]ffa0: 20000013 ffffffff



<3>[ 2587.111531][1]1fa4: [<c0013b40>] (0xc0013b40 __irq_svc+0x40/0x74)



<3>[ 2587.117637][1]1fd4: [<c0332be4>] (0xc0332be4 cpuidle_enter_state+0xe8/0x224)



<3>[ 2587.124697][1]1ff4: [<c0056c44>] (0xc0056c44 cpu_startup_entry+0x208/0x268)



<3>[ 2587.131663][1]3Code: ee1d2f90 e59f36f0 e7d30002 e3500000 (03a00001)



<3>[ 2587.138103][1]0Stack: (0xdec3fe60 to 0xdec40000)



<3>[ 2587.142810][1]0fe60: df7cb3a0 df7d0300 00000011 df7cb340 df7cb420 c06ad95c c06797c0 c006db60



<3>[ 2587.151331][1]0fe80: 0310767e 00000000 df0ce698 16bddd79 00000000 00000000 df0ce698 16bddd79



<3>[ 2587.159857][1]0fea0: 00000001 df057440 00000000 df7d0300 00000011 df012080 00000001 c06ad95c



<3>[ 2587.168382][1]0fec0: c06797c0 c006c750 0323f3c0 0000025a df7d0300 c0079f8c cd266190 c004d510



<3>[ 2587.176905][1]0fee0: c067e080 df7d0300 df011100 c0691080 00000011 df012080 e0804000 c0334c60



<3>[ 2587.185428][1]0ff00: df7d0300 c0062cec 00000011 00000000 00000000 00000001 df008000 c005ed4c



<3>[ 2587.193952][1]0ff20: c0677b10 c005efe8 0000001e e080400c c070a4dc dec3ff60 c067e748 c000946c



<3>[ 2587.202475][1]0ff40: c0332be4 20000013 ffffffff dec3ff94 0315b345 0000025a c06ad95c c0013b40



<3>[ 2587.210997][1]0ff60: dec3ffa8 00000018 0323f4e1 0000025a 0323f4e1 0000025a 00000001 df7ccec0



<3>[ 2587.219519][1]0ff80: 0315b345 0000025a c06ad95c c06797c0 13ffffc6 dec3ffa8 fffffff8 c0332be4



<3>[ 2587.228042][1]0ffa0: 20000013 ffffffff 0323f4e1 0000025a c06762a0 dec3e000 c067e4b8 c04b4c14



<3>[ 2587.236564][1]0ffc0: df7ccec0 dec3ffd8 c0676280 c06ad95c c06797c0 c0056c44 c0678eb8 c06b8182



<3>[ 2587.245086][1]0ffe0: c06797c0 00000000 1ec2804a c06ba2c0 00000000 000095cc bd17f36a bb5da1b7



<3>[ 2587.253692][1]Classified pointer on stack:



<3>[ 2587.257786][1]df7cb3a0 [page: type:reserved]



<3>[ 2587.262085][1]df7d0300 [page: type:reserved]



<3>[ 2587.266389][1]df7cb340 [page: type:reserved]



<3>[ 2587.270672][1]df7cb420 [page: type:reserved]



<3>[ 2587.274970][1]c006db60 hrtimer_run_queues+0xd8/0x118



<3>[ 2587.279997][1]df0ce698 [slab: type:kmalloc-64 size:128 start:0xdf0ce680+0x18 allocated by:0xc0336c94 __of_add_property_sysfs+0x6c/0xe0]



<3>[ 2587.292255][1]df057440 [slab: type:task_struct size:1216 start:0xdf057440+0x0 allocated by:0xc0025ca4 copy_process.part.3+0xe8/0x12e8]



<3>[ 2587.304380][1]df012080 [slab: type:kmalloc-64 size:128 start:0xdf012080+0x0 allocated by:0xc0061548 request_percpu_irq+0x50/0xf0]



<3>[ 2587.316028][1]c006c750 update_process_times+0x38/0x64



<3>[ 2587.321116][1]c0079f8c tick_handle_periodic+0x28/0x88



<3>[ 2587.326181][1]cd266190 [task_struct(kworker/1:2): cd266140+0x50]



<3>[ 2587.332185][1]c004d510 set_next_entity+0x58/0x3e4



<3>[ 2587.336920][1]df011100 [slab: type:kmalloc-192 size:256 start:0xdf011100+0x0 allocated by:0xc005ed80 alloc_desc+0x24/0x140]



<3>[ 2587.348060][1]e0804000 [ioremap : size:12288 start:e0804000+0x0 alloced by:0xc033a20c of_iomap+0x2c/0x34]



<3>[ 2587.357628][1]c0334c60 arch_timer_handler_phys+0x28/0x30



<3>[ 2587.362938][1]c0062cec handle_percpu_devid_irq+0x6c/0x84



<3>[ 2587.368314][1]df008000 [slab: type:kmalloc-2048 size:2112 start:0xdf008000+0x0 allocated by:0xc00638a8 __irq_domain_add+0x28/0xc0]



<3>[ 2587.380049][1]c005ed4c generic_handle_irq+0x2c/0x3c



<3>[ 2587.384933][1]c005efe8 __handle_domain_irq+0x5c/0xb4



<3>[ 2587.389930][1]e080400c [ioremap : size:12288 start:e0804000+0xc alloced by:0xc033a20c of_iomap+0x2c/0x34]



<3>[ 2587.399502][1]dec3ff60 [stack(swapper/1): dec3e000+0x1f60]



<3>[ 2587.405007][1]c000946c gic_handle_irq+0x54/0x118



<3>[ 2587.409630][1]c0332be4 cpuidle_enter_state+0xe8/0x224



<3>[ 2587.414741][1]dec3ff94 [stack(swapper/1): dec3e000+0x1f94]



<3>[ 2587.420267][1]c0013b40 __irq_svc+0x40/0x74



<3>[ 2587.424361][1]dec3ffa8 [stack(swapper/1): dec3e000+0x1fa8]



<3>[ 2587.429935][1]df7ccec0 [page: type:reserved]



<3>[ 2587.434267][1]dec3ffa8 [stack(swapper/1): dec3e000+0x1fa8]



<3>[ 2587.439774][1]c0332be4 cpuidle_enter_state+0xe8/0x224



<3>[ 2587.444828][1]Code: Code(0xc006a0ac): 0xe7d30002 0xe3500000 <0x03a00001> 0x01a0100d 0x07c30002



<3>[ 2587.453520][1]FASTIRQ-Status:



<3>[ 2587.456486][1]                CPU0        CPU1        CPU2



<3>[ 2587.462001][1]      48:          0           0           0     Watchdog       



<3>[ 2587.469198][1]     148:          0      641448           0     tdm_pcm          consum:min      9 max    125 avg     26 dt:min   2066 max 108994 avg   4000 us



<3>[ 2587.483160][1]     250:          0           0           0     monitor/0     



<3>[ 2587.490294][1]     251:          0           0           0     monitor/1     



<3>[ 2587.497426][1]     252:          0           0           0     monitor/2     



<3>[ 2587.504559][1]preempts:          0           0           0



<3>[ 2587.510128][1]spurious:         18          28           0



<3>[ 2587.515697][1]  consum:        0.0         0.6         0.0  %



<3>[ 2587.521437][1]



<3>[ 2587.521437][1]Backtrace of all other CPU's:



<3>[ 2587.525449][1]



<3>[ 2587.527286][1]CPU: 0 Pid: 0, comm:            swapper/0



<3>[ 2587.532507][1]       Tainted: P           O     (4.1.52 #1)



<4>[ 2587.538081][1]PC is at bcm_arm_cpuidle_wfi_enter+0x8/0x10



<4>[ 2587.543476][1]LR is at cpuidle_enter_state+0xd0/0x224



<3>[ 2587.548524][1]pc :[<c035a480>] lr :[<c0332bcc>] psr: 00000093



<3>[ 2587.548524][1]sp :  c067df70   ip :  00000000   fp : c06797c0



<3>[ 2587.559996][1]r10:  c06ad95c   r9 :  0000025a   r8 : 534f4149



<3>[ 2587.565736][1]r7 :  df7c0ec0   r6 : c04b4c14    r5 : 00000001 r4 : c06ad9fc



<3>[ 2587.572691][1]r3 :  c035a478   r2 : 00000001    r1 : c06ad95c r0 : c06c1fa0



<3>[ 2587.579648][1]Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel



<3>[ 2587.587125][1]Control: 10c5387d  Table: 0b81404a  DAC: 00000015



<3>[ 2587.593112][1]Classified pointer on registers:



<3>[ 2587.597552][1]r3 : c035a478 bcm_arm_cpuidle_wfi_enter+0x0/0x10



<3>[ 2587.603421][1]r6 : c04b4c14 cpu_online_mask+0x0/0x4



<3>[ 2587.608318][1]r7 : df7c0ec0 [page: type:reserved]



<3>[ 2587.613188][1]Backtrace:



<3>[ 2587.615733][1]1f6c: [<c035a480>] (0xc035a480 bcm_arm_cpuidle_wfi_enter+0x8/0x10)



<3>[ 2587.623131][1]1f9c: [<c0332bcc>] (0xc0332bcc cpuidle_enter_state+0xd0/0x224)



<3>[ 2587.630184][1]1fbc: [<c0056c44>] (0xc0056c44 cpu_startup_entry+0x208/0x268)



<3>[ 2587.637150][1]3Code: e5930000 e12fff1e f57ff04b e320f003 (e1a00002)



<3>[ 2587.643587][1]0Stack: (0xc067df70 to 0xc067e000)



<3>[ 2587.648288][1]0df60:                                     5a94d148 0000025a c06762a0 c067c000



<3>[ 2587.656810][1]0df80: c067e4b8 c04b4c14 df7c0ec0 c067dfa0 c0676280 c06ad95c c06797c0 c0056c44



<3>[ 2587.665332][1]0dfa0: c0678eb8 c06b8182 c06797c0 00000000 00000000 ffffffff 00000000 c0640c80



<3>[ 2587.673854][1]0dfc0: ffffffff ffffffff c064067c 00000000 00000000 c066fd30 c06ba258 c067e45c



<3>[ 2587.682375][1]0dfe0: c066fd2c c0683454 0000404a 410fc075 00000000 0000807c 00000000 00000000



<3>[ 2587.690949][1]Classified pointer on stack:



<3>[ 2587.695041][1]c04b4c14 cpu_online_mask+0x0/0x4



<3>[ 2587.699503][1]df7c0ec0 [page: type:reserved]



<3>[ 2587.703783][1]c0056c44 cpu_startup_entry+0x208/0x268



<3>[ 2587.708813][1]c0640c80 start_kernel+0x3b0/0x3bc



<3>[ 2587.713341][1]c064067c unknown_bootoption+0x0/0x1cc



<3>[ 2587.718345][1]



<3>[ 2587.720007][1]CPU: 2 Pid: 0, comm:            swapper/2



<3>[ 2587.725227][1]       Tainted: P           O     (4.1.52 #1)



<4>[ 2587.730796][1]PC is at bcm_arm_cpuidle_wfi_enter+0x8/0x10



<4>[ 2587.736190][1]LR is at cpuidle_enter_state+0xd0/0x224



<3>[ 2587.741237][1]pc :[<c035a480>] lr :[<c0332bcc>] psr: 00000093



<3>[ 2587.741237][1]sp :  dec41fa8   ip :  00000000   fp : c06797c0



<3>[ 2587.752708][1]r10:  c06ad95c   r9 :  0000025a   r8 : 5ec0c748



<3>[ 2587.758449][1]r7 :  df7d8ec0   r6 : c04b4c14    r5 : 00000001 r4 : c06ad9fc



<3>[ 2587.765404][1]r3 :  c035a478   r2 : 00000001    r1 : c06ad95c r0 : c06c5fa0



<3>[ 2587.772361][1]Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel



<3>[ 2587.779838][1]Control: 10c5387d  Table: 124ec04a  DAC: 00000015



<3>[ 2587.785817][1]Classified pointer on registers:



<3>[ 2587.790257][1]r3 : c035a478 bcm_arm_cpuidle_wfi_enter+0x0/0x10



<3>[ 2587.796180][1]r6 : c04b4c14 cpu_online_mask+0x0/0x4



<3>[ 2587.801089][1]r7 : df7d8ec0 [page: type:reserved]



<3>[ 2587.805985][1]Backtrace:



<3>[ 2587.808536][1]1fa4: [<c035a480>] (0xc035a480 bcm_arm_cpuidle_wfi_enter+0x8/0x10)



<3>[ 2587.815939][1]1fd4: [<c0332bcc>] (0xc0332bcc cpuidle_enter_state+0xd0/0x224)



<3>[ 2587.823004][1]1ff4: [<c0056c44>] (0xc0056c44 cpu_startup_entry+0x208/0x268)



<3>[ 2587.829976][1]3Code: e5930000 e12fff1e f57ff04b e320f003 (e1a00002)



<3>[ 2587.836418][1]0Stack: (0xdec41fa8 to 0xdec42000)



<3>[ 2587.841124][1]01fa0:                   6615a76e 0000025a c06762a0 dec40000 c067e4b8 c04b4c14



<3>[ 2587.849651][1]01fc0: df7d8ec0 dec41fd8 c0676280 c06ad95c c06797c0 c0056c44 c0678eb8 c06b8182



<3>[ 2587.858180][1]01fe0: c06797c0 00000000 1ec2804a c06ba2c0 00000000 000095cc cec63f32 b077e54c



<3>[ 2587.866851][1]Classified pointer on stack:



<3>[ 2587.870947][1]dec40000 [page: type:alloc]



<3>[ 2587.874965][1]c04b4c14 cpu_online_mask+0x0/0x4



<3>[ 2587.879428][1]df7d8ec0 [page: type:reserved]



<3>[ 2587.883729][1]c0056c44 cpu_startup_entry+0x208/0x268



<3>[ 2587.888784][1]cec63f32 [page: type:alloc by:0xc017f7b0 squashfs_copy_cache+0xdc/0x154]



<3>[ 2587.896713][1]



<3>[ 2587.896713][1]Backtrace of all other CPU's done



<3>[ 2587.896713][1]



<4>[ 2587.904551][1]---[ end trace 6ecb2cbe5c45bf45 ]---



<0>[ 2587.918750][1]Kernel panic - not syncing: Fatal exception in interrupt



-----



crashreport: read crash-variable '[0]f51b3592,61acb913,3[1]0,0,0[2]15e797ef,615f32fb,3[3]0,0,0'



crashreport: old parsed checksum[0].cs = f51b3592 new_sum=f6702284 (new_len=63027)



crashreport: crash-variable set to '[0]f6702284,b0,6[1]0,0,0[2]15e797ef,615f32fb,3[3]0,0,0'



(first) sent on: Thu Jan 01 00:02:56 1970 UTC by support data
 
Zuletzt bearbeitet:
Lösche mal oben besser alles vor dem Timestamp 2586 - da stehen im Moment noch IPv6-Adressen (und irgendwo auch eine IPv4-Adresse) drin und man kann (ohne Kenntnis, wer der Provider ist) nicht sicher sein, daß die nicht "quasi-statisch" sind, weil derselbe Kunde auch immer dieselben Adressen kriegt. Bei VF ist das (zumindest bei mir hier - VFKD über Kabel) bei IPv6 definitiv so ... wenn Du schnell bist, schaffst Du es vielleicht noch, bevor die Seite irgendwo archiviert wird und die Suchmaschinen, die den Inhalt schon haben, vergessen ihn auch wieder, wenn sie beim nächsten Mal die geänderte Seite indexieren.

Ansonsten ist das wohl ein Problem mit dem DECT - da wird das Timing alles "von Hand" gemacht und ist etwas zeitkritisch. Wobei das noch nicht erklärt, wieso irgendwelche inkonsistenten Daten es bis ins System schaffen - aber zumindest kann man durch Abschalten des DECT erst mal prüfen, ob der Rest sauber läuft. Ob das dann ein Hardware-Problem der Box ist oder eines der gekoppelten Geräte spinnt (oder die andere Antennencharakteristik der neuen Box im Vergleich zur 6591 eine Rolle spielt, etc.) oder irgendein anderer Störer noch dazwischen funkt (ich hoffe mal, die 6591 ist aus?) bzw. da vielleicht durch Übernahme der DECT-Keys aus der 6591 (oder sind die "von Hand" neu angemeldet an der 7530ax?) Probleme entstanden sind (die das auch nicht 100% erklären würden), kann man immer noch sehen, wenn man DECT als Ursache so festgemacht hat, daß keine weiteren Zweifel möglich sind (z.B. weil die Box dann auch durchläuft).

Je nachdem, wie die Antworten auf die Fragen oben dann ausfallen, sollte man dann weitersuchen ... die 6591 tatsächlich ausschalten (wenn's eine eigene ist, ist die womöglich tatsächlich noch irgendwo im Mesh aktiv?) oder zumindest mal auf Werkseinstellungen setzen und das ggf. bei der 7530ax auch noch einmal machen (und zwar zunächst auch ohne Wiederherstellen gesicherter Einstellungen) und die DECT-Geräte von Hand anmelden. Wenn DAS dann stabil läuft, kann man immer noch die anderen Einstellungen wiederherstellen lassen, wobei man dann die DECT-Settings tunlichst auslassen sollte.

Theoretisch dürfte es eben nicht vorkommen, daß ein DECT-PP mit zwei DECT-FP gleichzeitig(!) kommuniziert, weil eigentlich bei jeder Kopplung neue Keys ausgehandelt werden sollten - aber AVM hat (weil das ansonsten zum Marathon ausarten kann, wenn man die Box mal zurücksetzt und erst alle DECT-PPs ablaufen muß für erneute Kopplung) da wohl eine Übernahme dieser Daten (offenbar inkl. Keys, wobei das nirgends dokumentiert ist und nur aus den Abläufen geschlossen werden kann) in eine andere Box implementiert. Wenn das dann (reine Vermutung meinerseits) dazu führen sollte, daß beide DECT-FP gleichzeitig mit demselben PP kommunizieren wollen, könnte das zumindest zu falschen Nummerierungen und ähnlichem in den (ansonsten aber einwandfrei übertragenen) Frames führen. Das wäre die einzige, halbwegs plausible Erklärung, die mir dafür einfallen will, daß da lauter problematische DECT-Frames aufzutauchen scheinen. Ein Timing-Problem beim Empfang müßte m.E. anders aussehen, zumindest war das bei den MIPS-Modellen etwas deutlich anderes.
 
@PeterPawn Habs mal editiert. Die 6591 ist schon seit 30.11. nicht mehr im Betrieb. Die 7530 AX läuft übrigens bisher seit fast 3h problematisch. Bei DECT kann ich ja mal schauen ob ich den Fehler irgendwie triggern kann. Ich mein ich nutze die Fritz!Phones nur weil ich Sie mal im Büro genutzt habe und Sie quasi übrig waren. DECT nutze ich nur für die Thermostate.
 
Welche Beta?


Der Log sieht eher wie ein Speicherproblem aus.
Wenn es ein Speicherproblem ist, kann es helfen, die Option

"Diagnosedaten
Zur Verbesserung Ihres Produktes und für den sicheren Betrieb an Ihrem Anschluss übermittelt diese FRITZ!Box bei Bedarf Diagnosedaten, zum Beispiel Fehlerberichte, an AVM. So profitieren Sie von Optimierungen bei Updates oder notwendigen Anpassungen durch AVM."

Zu deaktivieren.
 
Habs mal editiert.
Offenbar aber nicht richtig/komplett. Wenn ich (in der neu geladenen Seite) suche, finde ich immer noch IPv6-Adressen, die mit 2003 starten. Alles zwischen "Panic#2 Part1" und der ersten Zeile mit 2586 kann auch weg (ist auch keine Kunst, daher stellt sich die Frage nicht wirklich).
 
  • Like
Reaktionen: Karl. und theGamer93
Sorry, hatte die grosse Schwester 7590_AX im Hinterkopf.
Btw. sollte @theGamer93 auch einen Blick auf APPs werfen, die ggfs. in die DECT-ULE Geschichte involviert ist neben Vorlagen, falls DECT als ursächlich ausgeguckt. Auch die Fritz!Fons und ihr FW-Stand sollten eines Blickes wert sein. Der Umzug/die Einstellungs-Übernahme von unterschiedlichen Modellen/inkl. FW- Ständen ist stets problematisch jedoch auch verständlich, da niemand wirklich Lust auf Resetten sämtlicher DECT/DECT-ULE- Devices mit anschließendem Neu-Anlernen hat.
LG
 
Vielleicht findet sich jetzt noch ein Moderator, der mit einem Text-Editor sicher umgehen kann und der entfernt die (beim Editieren per C&P) gerne mal entstehenden zusätzlichen Leerzeilen auf einen Rutsch - es ließe sich einfach besser lesen. Eigentlich sollte jeder halbwegs intelligente Editor in der Lage sein, solche "leeren Zeilen" mit einem Federstrich zu entfernen.



Leider kriegt es aber die Kombination aus Windows mit Firefox (Edge dürfte genauso problematisch sein und vielleicht auch noch div. andere Browser) und Xenforo seit einer Weile einfach nicht hin, den Text so ins Clipboard zu schreiben (zumindest nicht unter Windows, nach meiner Erfahrung), daß man beim Einfügen in einem Text-Editor keine überflüssigen Zeilenumbrüche hat.

Das liegt einfach daran, daß die Daten als "HTML Format" ins Clipboard geschrieben werden (https://docs.microsoft.com/en-us/windows/win32/dataxchg/html-clipboard-format) und wenn das dann als "nur Text" eingefügt werden soll an anderer Stelle, werden beim Konvertieren zusätzliche Zeilenumbrüche hinzugefügt.

Daran ist auch der WYSIWYG-Editor in Xenforo nicht ganz unschuldig (deshalb ist es eben die Kombination aus den o.a. Faktoren), weil er für jede Zeile im Editor einen getrennten Paragraphen (HTML-Element <p>) verwendet ... mit dem Ergebnis, daß dann eben nicht nur eine Textzeile, sondern jeweils ein Paragraph vom Browser im HTML-Format in die Zwischenablage kopiert wird. Markiert man hingegen mehrere Zeilen (die auch explizite Zeilenumbrüche enthalten) an anderer Stelle als im (Xenforo-)Editor, funktioniert es auch ohne zusätzliche Umbrüche, weil da eben nicht jede Zeile ein neues HTML-Element (bzw. sogar ein "Paragraph": https://www.w3schools.com/html/html_paragraphs.asp) ist.

Wie weit da jetzt auch noch die implizite Konvertierung zwischen "HTML-Format" und "nur Text" im Clipboard von Windows schuld ist, kann jeder selbst entscheiden - so ganz klar ist das "per Definition" halt auch nicht, ob da nun VOR dem Paragraphen noch ein zusätzlicher Zeilenumbruch erfolgen soll, zumal Browser üblicherweise auf diesem Weg entstehende, überflüssige Leerzeilen (im Text) dann wegoptimieren.

Das nur als Hinweis für andere, die auch desöfteren Text außerhalb des Xenforo-Editors bearbeiten ... die überflüssigen Leerzeilen, die (zumindest derzeit noch) im CODE-Kasten in #9 zu sehen sind und bei jedem Editieren offenbar mehr werden, entstehen immer dann, wenn man Text aus dem Editor-Teil der Seite in ein anderes Programm kopiert. Macht man das Kopieren nicht im Editor-Fenster (also schon bevor man das Edit in der Seite auswählt), entfallen auch die zusätzlichen Umbrüche.
 
  • Like
Reaktionen: theGamer93
Ich habe den kompletten Beitrag übrigens ausgeschnitten und in einen Texteditor gepackt. Anders ging es gar nicht, selbst das ausschneiden und wieder einfügen hat jeweils gut 2-3 Sekunden gedauert und war extrem träge. Keine Ahnung was da los ist. Ich nutze ein Macbook mit nem i9 + den aktuellen Chrome.

Back to Topic:

Bisher läuft die Box seit 15:00
 
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.