FB 5590: USB-Platte im NAS wird nicht erkannt (weder NVME noch SSD)

[white_rabbit]

Hallo.
Ich habe eine FB 5590 neu bekommen (Umstieg auf Glasfaser). Nun habe ich gesehen, dass das NAS endlich deutlich performanter läuft und so aussieht, als könne man es im Vergleich zur 7490 endlich mal nutzen . Daher habe ich zunächst eine NVME-Platte in einen USB-3.0-Adapter eingebaut und am hinteren USB-Port der FB eingesteckt. Die Platte wird in der FB erkannt (und zwar sowohl im 2.0 als auch im 3.0 Modus) aber wenn man auf das NAS wechselt, erscheint das Laufwerk nur sporadisch. Als es nach x Versuchen dann mal richtig eingebunden war, wollte ich ein dateibasiertes Backup von meinem Rechner über das Netzwerk auf den Stick schieben ... aber das klappt überhaupt nicht. Die FB ist hier des öfteren ausgestiegen und hat erstaunlicherweise auch mehrere Neustarts (Softresets) hingelegt.


Der zweite Versuch war daher eine SSD Platte in einem 2.5 Zoll Gehäuse zu nehmen und anzuschließen. Aber auch hier der gleiche Effekt: Die Platte wird in der FB unter "USB" richtig angezeigt. Das Dateisystem war in beiden Fällen EXT4. Wenn ich aber auf das NAS wechsele, erscheint das Verzeichnis für diese Platte aber nicht. So kann man damit also nichts anfangen. Ich frage mich nun natürlich, woran das scheitert?

Das Umstellen von USB 3.0 auf 2.0 hat übrigens nicht geholfen. Ebenso scheint es nicht an den Platten selbst zu liegen, denn am Laptop laufen beide Versionen fehlerfrei.
Auf der FB ist das aktuelle Fritz!OS 8.02 installiert (ohne weitere Änderungen).
Hat jemand eine Idee, woran das liegen kann?

 

[Grisu_]

Versuche einmal NTFS, ob es damit besser zurechtkommt.

 

[WoRiem]

Funktioniert hier mit 120 GB SSD in 2,5 Zoll Gehäuse an einer 7590 bestens.



Formatiert NTFS, angeschlossen über rückseitigen USB 3 Anschluss



Dient der regelmäßigen Sicherung der Outlook.pst & Archivierung.pst

Tipp > Anschließen, Index auf automatisch aktualisieren einstellen und nach 24 Stunden weitermachen

 

[white_rabbit]

Dass das evtl am automatischen Indizieren liegen kann, hatte ich auch schon vermutet. Gerade habe ich einen Test mit einem weiteren Adapter (Sabrent) gemacht .... auch da der gleiche Effekt! Und bei diesem Adapter habe ich auch mal den seitlichen USB-3.0-Eingang der FB ausprobiert: Keine Änderung!


Man sieht wieder, dass die Platte in der FB angezeigt wird -- aber im NAS taucht sie nicht auf. Hänge ich die Platte an meinen Laptop, wird sie fehlerfrei eingebunden (immernoch EXT4) und zeigt auch den Ordner "FRITZ" an, den die FB offenbar bereits erfolgreich angelegt hat.
Da wüsste ich echt mal gerne, was hier nicht stimmt?!?

 

[Erforderlich]

Die NAS-Ansicht sollte besser einen Ordner mit dem SSD-Label (bei mir HAOS_USB) und einem USB-Symbol enthalten:

Warum testest du nicht mal zur Abwechslung eine NTFS-formatierte SSD? Damit hatte ich noch nie irgendwelche Probleme.

 

[white_rabbit]

Ja, das ist bei mir aber nicht (oder nicht mehr) der Fall. Ich habe das Symbol ja schon gesehen -- deshalb weiß ich natürlich, dass es da sein müsste. Ist es aber leider nicht.
Die Sache mit NTFS würde ich eigentlich nicht so gerne umsetzen, da ich hier kein Windows verwende ... daher würde ich lieber bei EXT4 bleiben. Zumal: Die FB selbst läuft ja auch unter Linux. Die sollte mit EXT4-Laufwerken besser klar kommen als mit NTFS.

Ach ja: Natürlich habe ich die FB auch schon 2 Minuten vom Strom genommen und es dann neu versucht ... hat nichts gebracht.
Kann es denn sein, dass die Indizierung der Platte sooooo lange dauert? Da sind ja bereits Daten drauf, ich ich die Platte vorher lokal am Laptop verwendet habe und dort mit "Back in Time" eine Sicherung durchgeführt habe.
Das Symbol sollte aber doch unabhängig von der Indizierung sofort auftauchen, oder??

 

[Grisu_]

Du hast ja eh 2 Platten, dann mach eine leer und versuch es damit einmal, Schritt für Schritt (also dann nur das Benötigte rüberkopieren direkt als NAS und nicht jeden Müll obendrauf).

 

[WoRiem]

Ich hab einen leeren 2GB USB-Stick von FAT32 nach Ext4 gedreht. Der wurde nach dem Einstecken in den seitlichen USB 2.0 Anschluss sofort erkannt und stand auch, da leer. unmittelbar zur Verfügung.

Auf der SSD habe ich meine gesamt Musik und noch einiges drauf, die Erstindexierung hat recht lange gebraucht. Deshalb schrieb ich oben....

 

[white_rabbit]

Ja, ok -- ich kann die Platte nochmal neu einstecken und abwarten ... da sind etliche Files drauf.
Mir ist noch nicht ganz klar, warum das Erscheinen des Icons damit zusammenhängen soll, dass der Stick indiziert wird?? Das müsste doch unabhängig davon sowieso beim Mounten geschehen?
Und: Spätestens wenn man die Indizierung abschaltet, müsste der Pfad im NAS nach meinem Verständnis doch sofort erscheinen, oder? Tut er aber ebenfalls nicht...

Aber wie auch immer: Zunächst hänge ich die Platte nochmal so wie sie ist an den USB-Port und warte 24 Stunden .... Wenn das alles nicht hilft, kann ich sie von mir aus NTFS-formatieren (auch wenn das in meinen Augen nicht die eleganteste Lösung ist).

Nochmal zu den Backups, die ich angelegt habe: Da die Backups dateibasiert angelegt werden (und zwar mit "Back in Time"), sind es nunmal leider extrem viele Einzeldateien. Beim ersten Versuch mit dem 1TB-NVMe --> USB- Stick war es ja so, dass die Platte ganz am Anfang völlig leer war. Als das dann über das Netzwerk mit dem Backup alles nicht funktionierte, hatte ich ein Backup lokal direkt am Laptop angelegt. Daher war der Stick danach nicht mehr leer. Das sollte aber für ein NAS eigentlich kein Hindernis sein, würde ich meinen!??

 

[PeterPawn]

Das müsste doch unabhängig davon sowieso beim Mounten geschehen?

Das wird vermutlich auch der Fall sein - jedenfalls bei den Dateiserver-Diensten, die vom FRITZ!OS angeboten werden (SMB und FTP).

Die Ansicht im "NAS-GUI" (also auf dem HTTP-Server unter fritz.nas) benötigt aber einen (aktualisierten/aktuellen) Index und der steht (da das finale Update der dafür verwendeten sqlite3-Datenbanken sicherlich transaktional erfolgt) wohl erst nach dem Abschluss der (Index-)Operation zur Verfügung.

 

[white_rabbit]

Ok, das leuchtet ein.
Allerdings habe ich die FB soeben erneut abgeschossen!

Vorgehensweise dieses Mal: eine wesentlich kleinere 128 GB SSD an den Sabrent-Dongle gehängt, mit EXT4 formatiert und wieder hinten an die FB gehängt. Dieses Mal wurde die Platte sofort angezeigt (weil sie leer war) und das Icon erschien auch sofort.

Anschließend also ein neues Backup-Profil für "Back in Time" erstellt und als Ziel unter Linux das SMB-Share der FritzBox ausgewählt. Der Prozess startet dann, die ersten Dateien werden kopiert -- bis das Backup dann wieder aussteigt (mit der Meldung, dass die Ordner auf dem Share plötzlich angeblich nicht mehr angelegt werden können). Anschließend legt die FB einen Neustart hin.

Wenn ich die USB-Platte wieder unmounte und lokal hier an den Laptop hänge, wird das Dateisystem problemlos eingebunden und ich sehe, dass auf der Platte lediglich 259MB gelandet sind. Danach war offenbar Ende.
Mir ist weiterhin nicht klar, wo hier die Fehlerquelle zu suchen ist!?

(Das ist jetzt also die dritte Platte am dritten "SATA bzw NVME -> USB-Dongle" -- die können kaum alle defekt sein)

 

[NDiIPP]

Das Dateisystem war in beiden Fällen EXT4.

Bei ext2/3/4 als Dateisystem taucht da als erstes die Frage auf ob im root-Ordner des externen Speicher die passenden Rechte gesetzt wurden. Wenn nicht, weigert sich die Fritzbox dort irgendwas abzulegen…

 

[white_rabbit]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

... aber das kann in diesem Fall ja nicht zutreffen, denn dann würden da genau 0 Byte überkommen!
Es wurden aber immerhin 259 MB geschrieben.

Das SMB-Share der FB habe ich auf meinem Linux-Laptop mit diesem Eintrag in der /etc/fstab eingebunden:

//192.168.178.1/Fritz.NAS /mnt/fritz.NAS cifs noauto,users,username=<username>,password=<mein-passwort>,domain=WORKGROUP,uid=1000,gid=1000,vers=3.1.1,noserverino,dir_mode=0777,file_mode=0777,nounix 0 0

Das funktioniert und wird unter Linux (hier Kubuntu) anstandslos angezeigt (mit Schreibrechten)

 

[PeterPawn]

Anschließend legt die FB einen Neustart hin.

Da wäre es jetzt vermutlich nützlich, die Ursache für den beobachteten Neustart zu kennen (Supportdaten?).

 

[white_rabbit]

Hi. Ich habe mal einen Blick in die Support-Daten geworfen und schicke hier nur den letzten Abschnitt mit. Den extrem langen Teil vor der 22. Sekunde habe ich weggelassen ... es geht erst nach 39260 Sekunden mit dem Problem los, wie es aussieht?!

<5>[   22.542902][ T1504] audit: type=1700 audit(22.176:7): dev=pmapper1 prom=0 old_prom=256 auid=4294967295 uid=0 gid=0 ses=4294967295
<6>[   22.543078][ T1504] sw1: port 4(pmapper1) entered disabled state
<6>[   22.563087][ T1504] sw1: port 4(pmapper1) entered blocking state
<6>[   22.563108][ T1504] sw1: port 4(pmapper1) entered disabled state
<6>[   22.563780][ T1504] device pmapper1 entered promiscuous mode
<5>[   22.563828][ T1504] audit: type=1700 audit(22.196:8): dev=pmapper1 prom=256 old_prom=0 auid=4294967295 uid=0 gid=0 ses=4294967295
<6>[   22.564066][ T1504] sw1: port 4(pmapper1) entered blocking state
<6>[   22.564084][ T1504] sw1: port 4(pmapper1) entered forwarding state
<3>[   48.458685][    C1] start slab_allocator-trace now  (use cat /proc/slab_allocators)
<3>[39260.336957][    C0] [kernel-trap] pc=0x75959a20(0x75959a20 companion_other_panic_maybe.part.1+0x18/0x2c) addr=0x7c2edfa0 task=swapper/0 pid=0 ra=0x75959cd0(0x75959cd0 companion_other_panic_irq_handler+0x1c/0x4c)
<3>[39260.336975][    C0] Code(0x75959a18): 0x04400004 0x8fbf0014 <0x00020336> 0x00001025 0x8fbf0014
<0>[39260.337068][    C0] avm_set_reset_status: Soft-Reboot(KCRASH)  - KCRASH(1)UP(39259)UTC(1741033323)FW(08.02)HW(273)HWS(0)BV(1.12462)BN(117989)FS(08.02)BT(1)BD(0)
<3>[39260.350753][    C0] BUG() at function 'companion_other_panic_maybe' line: 38 file: /GU/KERNEL_prxI_build/src/main/linux/drivers/char/avm_new/avm_companion_panic.c
<6>[39260.364503][    C0] Kernel bug detected[#1]:
<4>[39260.368694][    C0] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O    4.9.276 #1
<4>[39260.376603][    C0] task: 75f3c7c0 task.stack: 75f1c000
<4>[39260.381793][    C0] $ 0   : 00000000 76260000 00000001 00000000
<4>[39260.387695][    C0] $ 4   : 7f84541c 00000013 75d80000 00000000
<4>[39260.393598][    C0] $ 8   : 01400000 0035d3b0 000023b4 9c000000
<4>[39260.399501][    C0] $12   : 00001c96 dd72cacb 7c2ec560 75f40000
<4>[39260.405424][    C0] $16   : 00000000 7fc07ed8 00000075 75f275c0
<4>[39260.411340][    C0] $20   : 75e2c024 75e2bffc 75f40000 00000000
<4>[39260.417213][    C0] $24   : 00000001 7552b17c                
<4>[39260.423112][    C0] $28   : 75f1c000 7fc07e50 7f098f80 75959cd0
<3>[39260.429016][    C0] Hi    : 00003321
<3>[39260.432576][    C0] Lo    : 9c000000
<3>[39260.436141][    C0] ac1Hi: 00000000 ac1Lo: 00000000
<3>[39260.440997][    C0] ac2Hi: 00000000 ac2Lo: 00000000
<3>[39260.445858][    C0] ac3Hi: 00000000 ac3Lo: 00000000
<3>[39260.450718][    C0] dspcontrol: 00000000
<3>[39260.454624][    C0] Status: 1100fc02    KERNEL EXL
<3>[39260.459228][    C0] Cause : 50800034 exc_code:13
<3>[39260.463942][    C0] epc   : 75959a20 0x75959a20 companion_other_panic_maybe.part.1+0x18/0x2c
<3>[39260.472335][    C0] errepc: 00000000   (null)
<3>[39260.476688][    C0] ra    : 75959cd0 0x75959cd0 companion_other_panic_irq_handler+0x1c/0x4c
<3>[39260.485009][    C0] Tainted: P           O  
<3>[39260.489349][    C0] PrId  : 0001a120 (MIPS interAptiv (multi))
<3>[39260.495318][    C0] Classified pointer on registers:
<3>[39260.500115][    C0]  $ 4 : 7f84541c [slab: type:kmalloc-192 size:256 start:0x7f845400+0x1c allocated by:0x758ce80c intel_pinctrl_probe+0x24c/0xd40]
<3>[39260.513482][    C0]  $14 : 7c2ec560 [page: type:alloc]
<3>[39260.518554][    C0]  $25 : 7552b17c r4k_wait_irqoff+0x0/0x40
<3>[39260.524180][    C0]  $30 : 7f098f80 [slab: type:kmalloc-64 size:128 start:0x7f098f80+0x0 allocated by:0x755a802c request_threaded_irq+0xd8/0x1c8]
<3>[39260.537100][    C0]  $31 : 75959cd0 companion_other_panic_irq_handler+0x1c/0x4c
<4>[39260.544384][    C0] Modules linked in: act_colmark arp_ndp_reinsert mod_pon_mcc(O) mcast_bridge_filter mod_pon_eth(O) mod_pon_mbox(O) intel_pon_hgu_vuni ppp_async crc_ccitt ppp_generic slhc pon_qos ppa_api(O) ppa_drv_stack_al(O) net_upstream_drv(O) cchardev(O) cprocfsmod(O) dc_mode_hw(O) directconnect_datapath(O) gwdpa_dpm(O) cpunet(O) ltq_eth_drv_xrx500 xrx500_phy_fw hui(O) eip123(O) eip123_hw(PO)
<4>[39260.579641][    C0] Process swapper/0 (pid: 0, threadinfo=75f1c000, task=75f3c7c0, tls=00000000)
<4>[39260.588396][    C0] Stack : 00000000 75b174e8 76123fa0 75f40000 7faf23b4 75959cd0 000023b4 7c2ed3a0
<4>[39260.597426][    C0]         00000000 00000000 00000000 755a5274 000023b4 7c2ec5f8 7f797d90 755ba3b8
<4>[39260.606451][    C0]         000023b4 d3cd0ab5 000023b4 75e30000 75f40000 00010000 75f275c0 fffdffff
<4>[39260.615479][    C0]         00020000 75f508e4 75f40000 00000000 00000001 755a53b4 00000000 00000001
<4>[39260.624507][    C0]         7c2ec574 7c2ec5d8 00000000 4a36be45 75f275c0 00010000 75f275d4 755a5468
<4>[39260.633535][    C0]         ...
<3>[39260.636725][    C0] Classified pointer on stack:
<3>[39260.641263][    C0] 75b174e8 gic_next_event+0x60/0xa8
<3>[39260.646325][    C0] 7faf23b4 [task_struct(irq/37-18100000): 7faf1fe0+0x3d4]
<3>[39260.653251][    C0] 75959cd0 companion_other_panic_irq_handler+0x1c/0x4c
<3>[39260.660014][    C0] 7c2ed3a0 [page: type:alloc]
<3>[39260.664518][    C0] 755a5274 __handle_irq_event_percpu+0x70/0x180
<3>[39260.670564][    C0] 7c2ec5f8 [page: type:alloc]
<3>[39260.675068][    C0] 7f797d90 [stack(fiber_monitor): 7f794000+0x3d90]
<3>[39260.681389][    C0] 755ba3b8 hrtimer_wakeup+0x1c/0x34
<3>[39260.686563][    C0] 755a53b4 handle_irq_event_percpu+0x30/0x88
<3>[39260.692287][    C0] 7c2ec574 [page: type:alloc]
<3>[39260.696757][    C0] 7c2ec5d8 [page: type:alloc]
<3>[39260.701298][    C0] 755a5468 handle_irq_event+0x5c/0x94
<3>[39260.706502][    C0] 7c2ec618 [page: type:alloc]
<3>[39260.711013][    C0] Call Trace:
<3>[39260.714106][    C0] [<75959a20>] 0x75959a20 companion_other_panic_maybe.part.1+0x18/0x2c
<3>[39260.722189][    C0] [<75959cd0>] 0x75959cd0 companion_other_panic_irq_handler+0x1c/0x4c
<3>[39260.730165][    C0] [<755a5274>] 0x755a5274 __handle_irq_event_percpu+0x70/0x180
<3>[39260.737543][    C0] [<755a53b4>] 0x755a53b4 handle_irq_event_percpu+0x30/0x88
<3>[39260.744690][    C0] [<755a5468>] 0x755a5468 handle_irq_event+0x5c/0x94
<3>[39260.751179][    C0] [<755a97e4>] 0x755a97e4 handle_edge_irq+0x1cc/0x230
<3>[39260.757770][    C0] [<755a4720>] 0x755a4720 generic_handle_irq+0x40/0x58
<3>[39260.764457][    C0] [<758cd874>] 0x758cd874 eqbr_irq_handler+0xf8/0x178
<3>[39260.771051][    C0] [<755a4720>] 0x755a4720 generic_handle_irq+0x40/0x58
<3>[39260.777746][    C0] [<7552b264>] 0x7552b264 do_IRQ+0x18/0x24
<3>[39260.783407][    C0] [<758be9c0>] 0x758be9c0 gic_shared_irq_vi5_dispatch+0x120/0x150
<3>[39260.791038][    C0] [<755290c4>] 0x755290c4 except_vec_vi_end+0xf0/0xf8
<3>[39260.797631][    C0] [<7552b1b0>] 0x7552b1b0 r4k_wait_irqoff+0x34/0x40
<3>[39260.804052][    C0] [<7559c5a8>] 0x7559c5a8 cpu_startup_entry+0x108/0x180
<3>[39260.810822][    C0] [<760dbc68>] 0x760dbc68 start_kernel+0x4cc/0x50c
<3>[39260.817149][    C0] Code: 8c840004  04400004  8fbf0014 <00020336> 00001025  8fbf0014  03e00008  27bd0018  27bdffc8
<4>[39260.827559][    C0]
<3>[39260.829749][    C0] ---- CPU_ID=1 CORE0 TC1 ----- (LINUX)
<3>[39260.835117][    C0] Status:  1100fc00 KERNEL
<3>[39260.839459][    C0] current: swapper/1 (pid: 0, threadinfo=7fc40000, task=7f84c620, sp=7fc43ec0 tls=0x00000000)
<3>[39260.849522][    C0] Call Trace:
<3>[39260.852656][    C0] [<7552b19c>] 0x7552b19c r4k_wait_irqoff+0x20/0x40
<3>[39260.859081][    C0] [<7559c5a8>] 0x7559c5a8 cpu_startup_entry+0x108/0x180
<3>[39260.865848][    C0] ---- CORE0 TC2 ----- (YIELD-Thread)
<3>[39260.871056][    C0] current: CPU0-YIELD-TC2 (pid: 0, threadinfo=7fc84000, task=7fc80620, sp=7fc87ec0 tls=0x00000000)
<4>[39260.881563][    C0] Call Trace:
<4>[39260.881569][    C0]
<4>[39260.886858][    C0]
<3>[39260.889022][    C0] ---- CORE0 TC3 ----- (YIELD-Thread)
<3>[39260.894236][    C0] current: CPU0-YIELD-TC3 (pid: 0, threadinfo=7fc94000, task=7fc90620, sp=7fc97ec0 tls=0x00000000)
<4>[39260.904731][    C0] Call Trace:
<4>[39260.904734][    C0]
<4>[39260.910039][    C0]
<3>[39260.912200][    C0] ---- CORE0 TC4 ----- (YIELD-Thread)
<3>[39260.917448][    C0] current: CPU0-YIELD-TC4 (pid: 0, threadinfo=7fc9c000, task=7fc98620, sp=7fc9fec0 tls=0x00000000)
<4>[39260.927918][    C0] Call Trace:
<4>[39260.927923][    C0]
<4>[39260.933213][    C0]
<3>[39260.935378][    C0] ---- CORE0 TC5 ----- (YIELD-Thread)
<3>[39260.940591][    C0] current: CPU0-YIELD-TC5 (pid: 0, threadinfo=7fcac000, task=7fca8620, sp=7fcafec0 tls=0x00000000)
<4>[39260.951086][    C0] Call Trace:
<4>[39260.951089][    C0]
<4>[39260.956390][    C0]
<3>[39260.958570][    C0] ---- CPU_ID=2 CORE1 TC0 ----- (LINUX)
<3>[39260.963938][    C0] Status:  1100fc00 KERNEL
<3>[39260.968280][    C0] current: swapper/2 (pid: 0, threadinfo=7fc44000, task=7f848cc0, sp=7fc0fdd8 tls=0x00000000)
<3>[39260.978355][    C0] Call Trace:
<3>[39260.981482][    C0] [<75597f04>] 0x75597f04 enqueue_task_rt+0x54/0x3a8
<3>[39260.987995][    C0] [<7557df80>] 0x7557df80 ttwu_do_activate+0x5c/0xa0
<3>[39260.994521][    C0] [<7557f35c>] 0x7557f35c sched_ttwu_pending+0x94/0xd4
<3>[39261.001199][    C0] [<755806ec>] 0x755806ec scheduler_ipi+0xac/0x158
<3>[39261.007533][    C0] [<75533ad0>] 0x75533ad0 ipi_resched_interrupt+0x10/0x20
<3>[39261.014475][    C0] ---- CORE1 TC1 ----- (MPEFW)
<3>[39261.019062][    C0] Status:  00000401 KERNEL IE
<3>[39261.023676][    C0] [<800037f0>] 0x800037f0
<3>[39261.023676][    C0] [<80003ad0>] 0x80003ad0
<3>[39261.023676][    C0]
<3>[39261.034245][    C0] ---- CORE1 TC2 ----- (YIELD-Thread)
<3>[39261.039470][    C0] current: CPU2-YIELD-TC2 (pid: 0, threadinfo=7fc8c000, task=7fc88620, sp=7fc8fea8 tls=0x00000000)
<3>[39261.049984][    C0] Call Trace:
<3>[39261.053104][    C0] [<7588c1f8>] 0x7588c1f8 monitor_ipi_yield_context+0x264/0x294
<3>[39261.060557][    C0] [<7588bfb0>] 0x7588bfb0 monitor_ipi_yield_context+0x1c/0x294
<4>[39261.067935][    C0] ---[ end trace 5f04e3a0a2368afc ]---
<0>[39261.096486][    C0] Kernel panic - not syncing: Fatal exception in interrupt
<4>[39261.102211][    C0] Kernel relocated by 0x05520000
<4>[39261.106843][    C0]  .text @ 0x75520000
<4>[39261.110662][    C0]  .data @ 0x75d48eb8
<4>[39261.114482][    C0]  .bss  @ 0x76260000
-----
crashreport: read crash-variable '67f8d8ff,67c751eb,6:0,0,0:0,0,0:0,0,0:ada5a012,67c751c3,6:b51ea3fa,67c751c3,6'
crashreport: old parsed checksum[1]: .cs=00000000 .crc32=00000000; new: .cs=085cc6b7 .crc32=262a0010 (new_len=67607)
crashreport: crash-variable set to '67f8d8ff,67c751eb,6:262a0010,67c751eb,6:0,0,0:0,0,0:ada5a012,67c751c3,6:b51ea3fa,67c751c3,6'
(first) sent on: Tue Mar 04 19:18:03 2025 UTC by support data
----------
##### END SECTION '/proc/avm/log_sd/panic2'

==========
##### END SECTION PANICLOG
##### END SECTION Support_Data
End Of Support Data

 

[PeterPawn]

Man müßte sich jetzt mal die Quellen ansehen - ansonsten kann man nur "schätzen", wo das Problem liegt.

Offenbar gibt es in einer Interrupt-Behandlung eine Exception, die (vielleicht auch, weil AVM mit dem eigenen Yield-Mechanismus vollständige Kontextwechsel für die Behandlung von Interrupts vermeiden will, weil diese "teuer" sind und AVM den Prozessoren mehr an zusätzlicher Arbeit aufhalst, als andere) dann nicht mehr korrekt behandelt wird/werden kann.

Interessant wäre hier noch, ob das Problem reproduzierbar (d.h. auch an derselben Stelle) auftritt - nach meiner (unsicheren) Interpretation steht das System einigermaßen unter Stress (zumindest ist der swapper-Prozess auf mind. einem Core gerade am Wirken und das passiert eigentlich nur dann, wenn da zu wenig (echter) Hauptspeicher verfügbar ist) und das kann gut und gerne auch daran liegen, daß da offenbar viele Dateihandle in schneller Folge geöffnet und geschlossen werden - zumal AVM wohl dem eingekauften SMB-Server selbst nicht so richtig traut(e), denn dem hatte man einen extra Watchdog spendiert, der ihn nach Abstürzen wieder ans Laufen bringen sollte. Vielleicht hat man aber diese Probleme inzwischen auch beseitigt - ich habe schon länger keine GRX-Firmware näher untersucht (sollte es den Watchdog immer noch geben, steht der in der Prozessliste).

Ob es am SMB-Server liegt, kann man relativ einfach feststellen - einfach mal den FTP-Server verwenden, auch wenn der für inkrementelle Backups nichts taugt (weil jede Datei das Datum des Schreibens als (einzigen) Zeitstempel erhält) - aber über den könnte man auch in schneller Folge viele kleinere Dateien schreiben lassen.

Alternative "Probe" (auch "zusätzlich") wäre das Verwenden einer einzelnen Containerdatei für das Backup (halt irgendwo auf dem PC in ein Verzeichnis archivieren und dieses dann gepackt als einzelnes File auf der Box ablegen lassen) - sollte auch das klappen, dürfte die Annahme, daß der nqcs eben doch (immer noch) nicht sauber arbeitet, an Wahrscheinlichkeit zulegen.

So eine FRITZ!Box ist eben doch kein "richtiger" NAS - noch dazu mit dem eingekauften SMB-Server (https://www.ip-phone-forum.de/threads/unter-die-haube-geschaut-Änderungen-neuigkeiten-im-fritz-os-der-labor-reihe-07-19.305167/post-2351246).