AVM-Watchdog - kann man den guten gewissen deaktivieren?

ICh bekomme ja gar kein orginales Fritz!OS drauf. KA warum.
Momentan sehe ich nur ein Recover.
Aber dann ist es wieder ein Aufwand der Fritz!Box zu erklären, dass sie ein Freetz Image annehmen soll... -__-

Ich habe meinen Rechner in einem anderen Fenster als die Fritzbox, immer wenn ich zur Fritz!Box geschaut habe, hat nur die Power-Leuchte geleuchtet.
 
Momentan sehe ich nur ein Recover.
Aber dann ist es wieder ein Aufwand der Fritz!Box zu erklären, dass sie ein Freetz Image annehmen soll... -__-
Welcher Aufwand? Wenn Dein 07.21 immer wieder abstürzt, mußt Du ja danach offenbar auch per Bootloader auf die 07.12 zurückschalten - das Installieren eines anderen Systems ist praktisch genau dasselbe, nur mit anderen Skript-Dateien. Und dann braucht es kein Recovery-Programm - das steht erst dann an, wenn die Box tatsächlich schon mit der originalen Firmware 07.21 nicht läuft, solange die aktuellen Einstellungen vorhanden sind.
 
Ich pausiere hier erstmal, da ich momentan ein wenig den Eindruck habe, das meine Fritz!Box erstmal zum Doktor muss, mache dafür einen neuen Thread auf...
 
Mach doch einfach ein AVM recovery
 
Mach doch einfach ein AVM recovery
Der Box aber dann Freetz bei zu bringen ist ne halbe Zumutung.

@PeterPawn Scripts will ich nicht nutzen, weil für deren Nutzung nicht fähig genug bin um sie zu verstehen.
Was war das letzte Recover welches ohne signier-Prüfung funktioniert?

Aber besser hier weiter https://www.ip-phone-forum.de/threads/fb7590-startet-nicht-mehr-auf-befehl-neu-und-update-auf-7-21-schlägt-fehl.308479/ , da das nichts mit dem Thema zu tun hat.
Hier können wir weiter machen, wenn meine FB7590 wieder geheilt ist...
 
Sowas gibt es nicht für die 7590! Wenn ein Reboot (wird automatisch nach flashen gemacht) nicht geht, hängt evtl irgend ein daemon oder zombie.
Da du deine AVM Konfiguration eh zerhauen hast, wäre ein recovery ganz gut. Und dazu können die Freetz Settings durch das addon durcheinander kommen - selbst wenn es nicht mehr installiert ist (https://freetz-ng.github.io/freetz-ng/ADDONS)
 
Scripts will ich nicht nutzen, weil für deren Nutzung nicht fähig genug bin um sie zu verstehen.
Sorry ... dann bin ich raus - ich habe mich ohnehin viel mehr in die Sache hineinziehen lassen, als ich es wollte (was ich oben auch schon klargestellt hatte).

Mir ist einigermaßen unklar, wie man bei diesem Standpunkt überhaupt auf die Idee kommt, die originale Firmware zu modifizieren - oder willst Du damit sagen, daß Du von Freetz genug verstehst, um das dort einschätzen zu können?

Ich kann auch noch verstehen, wenn man einem Projekt so weit vertraut, daß man das nicht unbedingt hinterfragen will - aber da solche Projekte wie Freetz (und selbstverständlich auch Freetz-NG) ja auf anderen Projekten aufsetzen, MUSS man dieses Vertrauen quasi zwangsweise auf die dort genutzten, anderen Projekte ausweiten und wenn Du bisher (das originale) Freetz genutzt hast, dann hat das wiederum ja auch meine Skript-Dateien verwendet, um den Benutzern die Installation ihres ersten Images zu ermöglichen.

Da ist dann der zwar kleine, aber hier doch erhebliche Umstand, daß es bei der 7590 gar keine FRITZ!OS-Version (offiziell) gab, die ihrerseits die Signatur eines Images nur oberflächlich prüfte oder der man noch sagen konnte: "Scheißegal, installiere das mal trotzdem.", nur noch das Sahnehäubchen - mit meinem Unverständnis als "cherry on top".

@cuma:
Was willst Du denn immer mit dem AddOn? Wie kommst Du auf die Idee, daß das für @JokerGermany eine Rolle spielt oder daß er das bisher verwendet hat?

Nach #1 hat er bisher ein vollkommen normales Freetz-Image genutzt und zwar auch ein selbst erstelltes (von irgendwelchen AddOns lese ich da nichts) und jetzt will er (wohl oder übel) Freetz-NG eine Chance geben.

Warum willst Du ihm da immer irgendwelche Zusammenhänge mit fremden AddOns reinsingen?
 
@fda89:
Dein DEB gebashe geht mir ganz schön auf die nerven.
Nicht weil ich DEB Nutzer bin, ich bin erst durch eure Flames hier im Forum überhaupt darüber in Kenntnis gesetz worden, was ihr so in etwa meinen KÖNNTET.
Die Addons die momentan auf der 7590 mit 7.12 und normalen ROCKSTABILEN Freetz laufen sind:
Bind, Callmonitor, Dnsmasq, Halt-On-Lan, OpenVPN, Wake on LAN, Wireguard

Um es mal mit deinen Worten zu formulieren:
Die 7.12 mit Freetz lief stabil
Mit stabil meine ich, dass die eine Uptime seit Juli 2020 hatte und das auch nur weil ich da versucht habe eine ständig abstützendes Freetz-NG zu flashen.
 
Zuletzt bearbeitet:
Weil das Addon noch Auswirkungen haben kann, selbst wenn es aktuell nicht mehr installiert ist! Und ich weiss ja dass er auch im DEB unterwegs ist.
Ich hab schon viel zu oft Fehler gesucht und Zeit verschwendet die durch dieses ausgelöst wurden.

EDIT: Ich seh das aber wie PeterPawn, es macht keinen Sinn hier weiterzumachen
 
Mir ist einigermaßen unklar, wie man bei diesem Standpunkt überhaupt auf die Idee kommt, die originale Firmware zu modifizieren - oder willst Du damit sagen, daß Du von Freetz genug verstehst, um das dort einschätzen zu können?


Ich kann auch noch verstehen, wenn man einem Projekt so weit vertraut, daß man das nicht unbedingt hinterfragen will - aber da solche Projekte wie Freetz (und selbstverständlich auch Freetz-NG) ja auf anderen Projekten aufsetzen, MUSS man dieses Vertrauen quasi zwangsweise auf die dort genutzten, anderen Projekte ausweiten und wenn Du bisher (das originale) Freetz genutzt hast, dann hat das wiederum ja auch meine Skript-Dateien verwendet, um den Benutzern die Installation ihres ersten Images zu ermöglichen.

Ich habe kein Problem Skripts auszuführen, aber deine Skripts laufen bei mir einfach selten bis nie OOTB.

Jedes Problem damit führt für mich Tagelanges googlen und Recherchieren inklusive Schnitzeljagd deinerseits bedeuten. Am Ende war es dann eine Belanglosigkeit, die mich allerdings Tage gekostet haben. Das ist Kräfte und nerven zehrend. Wir passen nicht zusammen und ich bin absolut nicht so firm wie du und das sorgt für Probleme.
Das ist der Grund, warum ich das gerne umgehen würde. Nicht weil ich deine Arbeit und deine Skripte nicht schätze.


Weil das Addon noch Auswirkungen haben kann, selbst wenn es aktuell nicht mehr installiert ist! Und ich weiss ja dass er auch im DEB unterwegs ist.

Mein Nickname war mal im DEB, du hast mich überführt, sie können mich abführen...

jokergermany. Newbie. Mitglied seit: 23. Dezember 2013. Zuletzt gesehen: 23. Dezember 2013

Gut das die FB7590 knapp 7 Jahre alt ist...
Woher weißt du eigentlich was jokergermany im DEB Forum wollte?
 
Zuletzt bearbeitet:
Ich habe kein Problem Skripts auszuführen, aber deine Skripts laufen bei mir einfach selten bis nie OOTB.

Jedes Problem damit führt für mich Tagelanges googlen und Recherchieren inklusive Schnitzeljagd deinerseits bedeuten.
Wie ich schon weiter vorne geschrieben hatte, brauchst Du ja nur die Skript-Dateien benutzen, die sich ohnehin in Deinem Freetz-Checkout befinden - die sind bereits so geändert, daß sie auch unter Debian-Systemen funktionieren, wenn man bei ihrem Aufruf auch tatsächlich die passenden Parameter angibt - und die sind wieder hier beschrieben und - in diesem konkreten Fall sogar "angepinnt" - in keinster Weise irgendwie "versteckt".

Und da nehme ich es Dir jetzt tatsächlich übel, daß Du das als "Schnitzeljagd" bezeichnest, denn ich habe das nun wirklich ausführlich genug beschrieben (halt nicht exklusiv für Dich, aber Deine Probleme (zumindest die hier berichteten) sind da auch alle gelöst), so daß andere damit offenbar auch zurechtkommen - und ich hatte Dich ausdrücklich darauf hingewiesen, daß diese Beschreibungen existieren und wo sie hier im IPPF angepinnt sind ... siehe hier.

Ich weiß also nicht, ob Deine "tagelangen Suchen" jetzt nur als stilistisches Mittel zur Verdeutlichung eines hohen Aufwands für Dich dienten oder ob das tatsächlich den benötigten Zeiträumen nahe kommt - ist letzteres wirklich der Fall, verstehe ich ohnehin nicht, wie es dazu kommen kann ... zumindest nicht bei den von Dir berichteten Problemen.

Wenn mir tatsächlich jemand eine Fehlerbeschreibung für meine Software liefert, die ich nicht schon mehrfach gehört/gelesen habe, widme ich mich i.d.R. auch dem dahinter stehenden Problem und schicke die Leute nicht einfach nur "Lesen", weil es dann die Beschreibung zur Lösung offensichtlich noch nicht gibt.

Wenn das für Dich nicht ausreichend ist, hast Du mit Deiner Annahme, daß wir "nicht zueinander passen" tatsächlich recht - damit macht es ja dann erst recht Sinn, wenn ich mich ab jetzt heraushalte.
 
@PeterPawn
Soweit ich verstehe löst der untrustedd den reboot aus. Mehr aber auch nicht
Der Watchdogtimeout war auf 6 Minuten gesetzt, reboot erfolgte vermutlich schon früher (nach "uptime")
Aus syslog:
Code:
0  kernel: [  212.467895] [3]AVM_WATCHDOG_reboot(hdl=5, untrustedd): reboot (current: swapper/3 oom_score 0)
0  kernel: [  212.475182] pagefaults absolut 560494 since last untrustedd-trigger 422162
0  kernel: [  212.484315]   hdl= 2 supervisor    pid  698 triggered before:   8.720 s(avg   9.416 s) state S cpu1 pgfault      0 oom_score 172
0  kernel: [  212.495003]   hdl= 3 boxnotifyd    pid 3573 triggered before:   2.072 s(avg  19.016 s) state S cpu1 pgfault      0 oom_score 326
0  kernel: [  212.506045]   hdl= 4 run_clock     pid 3574 triggered before: 164.236 s(avg   0.008 s) state S cpu2 pgfault      0 oom_score 20
0  kernel: [  212.517622]   hdl= 5 untrustedd    pid 3621 triggered before: 163.596 s(avg   0.000 s) state S cpu3 pgfault      1 oom_score 222
0  kernel: [  212.529015]  force SIGBUS for untrustedd (pid= 3621)
0  kernel: [  212.533997]   hdl= 6 avmnexusd     pid 3712 triggered before:   2.384 s(avg   8.640 s) state S cpu1 pgfault      3 oom_score 1009
0  kernel: [  212.545628]   hdl= 7 l2tpv3d       pid 3759 triggered before:   2.848 s(avg   9.996 s) state S cpu0 pgfault      0 oom_score 474
0  kernel: [  212.557184]   hdl= 8 dsl_monitor   pid 3769 triggered before:   1.488 s(avg  21.444 s) state S cpu1 pgfault      0 oom_score 469
0  kernel: [  212.568725]   hdl= 9 ctlmgr        pid 3777 triggered before:   1.624 s(avg   7.292 s) state S cpu2 pgfault     26 oom_score 3579
0  kernel: [  212.580359]   hdl=24 upnpd         pid 3783 triggered before:   8.360 s(avg   8.344 s) state S cpu1 pgfault     10 oom_score 1137
0  kernel: [  212.592080]   hdl=10 multid        pid 3887 triggered before:   5.544 s(avg   8.684 s) state S cpu3 pgfault      1 oom_score 871
0  kernel: [  212.603669]   hdl=11 pcpd          pid 3995 triggered before:   3.600 s(avg   8.640 s) state S cpu0 pgfault      0 oom_score 455
0  kernel: [  212.615083]   hdl=12 wland         pid 4014 triggered before:  59.536 s(avg  13.388 s) state S cpu3 pgfault     11 oom_score 1279
0  kernel: [  212.626710]   hdl=13 usermand      pid 4089 triggered before:   0.240 s(avg   8.560 s) state S cpu0 pgfault      0 oom_score 549
0  kernel: [  212.638255]   hdl=14 dsld          pid 4097 triggered before:   8.304 s(avg   8.544 s) state S cpu0 pgfault      0 oom_score 829
0  kernel: [  212.650092]   hdl=15 deviceinfod   pid 4151 triggered before:   8.292 s(avg   8.456 s) state S cpu1 pgfault      0 oom_score 444
0  kernel: [  212.661388]   hdl=18 aha           pid 4153 triggered before:  26.776 s(avg  30.000 s) state S cpu3 pgfault      6 oom_score 1245
0  kernel: [  212.672981]   hdl=16 kpid          pid 4154 triggered before:   8.124 s(avg   8.448 s) state S cpu0 pgfault      0 oom_score 590
0  kernel: [  212.684564]   hdl=17 pbd           pid 4264 triggered before:  65.752 s(avg  10.220 s) state S cpu2 pgfault      0 oom_score 787
0  kernel: [  212.696227]   hdl=19 telefon       pid 4701 triggered before:  55.524 s(avg  11.892 s) state S cpu2 pgfault      3 oom_score 1344
0  kernel: [  212.707707]   hdl=20 mobiled       pid 4815 triggered before:  53.484 s(avg  91.856 s) state S cpu3 pgfault      0 oom_score 518
0  kernel: [  212.719288]   hdl=21 faxd          pid 4903 triggered before:   3.096 s(avg   2.880 s) state S cpu2 pgfault      0 oom_score 695
0  kernel: [  212.730829]   hdl=22 meshd         pid 4968 triggered before:   4.120 s(avg   6.084 s) state S cpu1 pgfault      0 oom_score 1743
0  kernel: [  212.742425]   hdl=23 voipd         pid 5110 triggered before:   2.932 s(avg   8.448 s) state S cpu3 pgfault      3 oom_score 2069
0  kernel: [  212.755788] ar7wdt_hw_reboot: kernel context for untrustedd (pid= 3621):
6  kernel: [  212.761064] untrustedd      S    0  3621    698 0x08100000
4  kernel: [  212.766513] Stack : 00000200 9f76bd40 9ecb3cc0 00000030 175d7200 9ef62330 00000000 9e01bdec
4  kernel: [  212.774842]         9f3e0790 9f41bd40 9e01bd98 806a0cb8 771a7000 00000030 9e01be30 00000000
4  kernel: [  212.783175]         9fe51c00 9e01be3c 00000002 7fa704a4 00000000 ffffffff 5571a2b4 80c8a5a0
4  kernel: [  212.791507]         9e01be30 00000000 9fe51c00 9e01be3c 00000002 805afc68 00000030 175d7200
4  kernel: [  212.799849]         00000030 00000002 00000000 00000000 00000080 00000000 00000002 00000000
4  kernel: [  212.808169]         ...
3  kernel: [  212.810854] Classified pointer on stack:
3  kernel: [  212.814518] 9f76bd40 [task_struct(untrustedd): 9f76bd40+0x0]
3  kernel: [  212.820300] 9ecb3cc0 [slab: type:kmalloc-192 size:192 start:0x9ecb3cc0+0x0]
3  kernel: [  212.827541] 9ef62330 [slab: type:shmem_inode_cache size:384 start:0x9ef62300+0x30]
3  kernel: [  212.834879] 9e01bdec [stack(untrustedd): 9e018000+0x3dec]
3  kernel: [  212.840186] 9f3e0790 [slab: type:vm_area_struct size:88 start:0x9f3e0790+0x0]
3  kernel: [  212.847221] 9f41bd40 [task_struct(untrustedd): 9f41bd40+0x0]
3  kernel: [  212.852849] 9e01bd98 [stack(untrustedd): 9e018000+0x3d98]
3  kernel: [  212.858190] 806a0cb8 current_time+0x6c/0x88
3  kernel: [  212.862565] 9e01be30 [stack(untrustedd): 9e018000+0x3e30]
3  kernel: [  212.867995] 9fe51c00 [page: type:alloc]
3  kernel: [  212.871612] 9e01be3c [stack(untrustedd): 9e018000+0x3e3c]
3  kernel: [  212.877366] 80c8a5a0 schedule+0x70/0xac
3  kernel: [  212.880827] 9e01be30 [stack(untrustedd): 9e018000+0x3e30]
3  kernel: [  212.886387] 9fe51c00 [page: type:alloc]
3  kernel: [  212.890015] 9e01be3c [stack(untrustedd): 9e018000+0x3e3c]
3  kernel: [  212.895358] 805afc68 futex_wait_queue_me+0x114/0x15c
3  kernel: [  212.901561] 805b0cc4 futex_wait+0x120/0x298
3  kernel: [  212.904743] 9f3e0790 [slab: type:vm_area_struct size:88 start:0x9f3e0790+0x0]
3  kernel: [  212.911719] 9ef62330 [slab: type:shmem_inode_cache size:384 start:0x9ef62300+0x30]

Code:
20:00:25 up 3 min,  load average: 2.90, 2.16, 0.92
hdl= 2 supervisor    pid  698 triggered before:   5.944 s(avg   9.516 s) state: S cpu1 pgfault      0 oom_score 52
hdl= 3 boxnotifyd    pid 3573 triggered before:   9.532 s(avg  19.016 s) state: S cpu1 pgfault      0 oom_score 52
hdl= 4 run_clock     pid 3574 triggered before: 171.684 s(avg   0.008 s) state: S cpu2 pgfault      0 oom_score 52
hdl= 6 avmnexusd     pid 3712 triggered before:   9.804 s(avg   8.640 s) state: S cpu0 pgfault      3 oom_score 52
hdl= 7 l2tpv3d       pid 3759 triggered before:   0.256 s(avg   9.996 s) state: S cpu0 pgfault      0 oom_score 52
hdl= 8 dsl_monitor   pid 3769 triggered before:   8.884 s(avg  21.444 s) state: S cpu1 pgfault      0 oom_score 52
hdl= 9 ctlmgr        pid 3777 triggered before:   9.008 s(avg   7.292 s) state: S cpu0 pgfault     26 oom_score 52
hdl=24 upnpd         pid 3783 triggered before:   5.732 s(avg   8.548 s) state: S cpu1 pgfault     10 oom_score 52
hdl=10 multid        pid 3887 triggered before:   2.904 s(avg   8.848 s) state: S cpu3 pgfault      1 oom_score 52
hdl=11 pcpd          pid 3995 triggered before:   0.956 s(avg   8.808 s) state: S cpu2 pgfault      0 oom_score 52
hdl=12 wland         pid 4014 triggered before:  66.876 s(avg  13.388 s) state: S cpu1 pgfault     11 oom_score 52
hdl=13 usermand      pid 4089 triggered before:   7.568 s(avg   8.560 s) state: S cpu0 pgfault      0 oom_score 52
hdl=14 dsld          pid 4097 triggered before:   5.620 s(avg   8.724 s) state: S cpu0 pgfault      0 oom_score 52
hdl=15 deviceinfod   pid 4151 triggered before:   5.596 s(avg   8.648 s) state: S cpu1 pgfault      0 oom_score 52
hdl=18 aha           pid 4153 triggered before:   4.068 s(avg  30.000 s) state: S cpu3 pgfault      6 oom_score 52
hdl=16 kpid          pid 4154 triggered before:   5.404 s(avg   8.640 s) state: S cpu0 pgfault      0 oom_score 52
hdl=17 pbd           pid 4264 triggered before:  73.020 s(avg  10.220 s) state: S cpu2 pgfault      0 oom_score 52
hdl=19 telefon       pid 4701 triggered before:  62.780 s(avg  11.892 s) state: S cpu0 pgfault      3 oom_score 52
hdl=20 mobiled       pid 4815 triggered before:  60.732 s(avg  91.856 s) state: S cpu3 pgfault      0 oom_score 52
hdl=21 faxd          pid 4903 triggered before:   0.324 s(avg   2.884 s) state: S cpu2 pgfault      0 oom_score 52
hdl=22 meshd         pid 4968 triggered before:   1.600 s(avg   5.008 s) state: S cpu1 pgfault      0 oom_score 52
hdl=23 voipd         pid 5110 triggered before:   0.144 s(avg   8.640 s) state: S cpu2 pgfault      3 oom_score 52
hdl= 5 untrustedd    triggered before: 171.032 s(avg   0.000 s) maybe crashed

Da jetzt das Kernellog aktiviert ist hab ich dies zufällig nach 3h uptime (watchdog deaktiviert) entdeckt
Code:
4  kernel: [10712.315067][1]------------[ cut here ]------------
4  kernel: [10712.315250][1]WARNING: CPU: 1 PID: 0 at /GU/KERNEL_grx5_build/linux/drivers/net/ethernet/lantiq/ltq_toe_drv.c:1002 0x80a76bf0 lro_timer_fn+0x28/0x48
4  kernel: [10712.315268][1]Modules linked in: nfsv2 nfsv3 nfs lockd sunrpc grace cifs md4 autofs4 krtp(PO) usb_storage xhci_plat_hcd xhci_hcd qca_ol(O) umac(O) userman_mod(PO) ath_spectral(PO) ath_dfs(PO) qdf(O) asf(PO)
4  kernel: [10712.315912][1]CPU: 1 PID: 0 Comm: swapper/1 Tainted: P           O    4.9.198 #1
4  kernel: [10712.315928][1]Stack : 00000000 80582318 00000000 00000004 00000001 00000016 00000000 00000000
4  kernel: [10712.316033][1]        00000000 00000000 810d903a 00000042 80cf0000 00000000 00000000 00000000
4  kernel: [10712.316134][1]        9fca406c 80e8d147 80d95640 00000001 00000000 810d4c24 00000101 80e74044
4  kernel: [10712.316237][1]        00000082 80582378 810f0000 80e90000 80e96240 00000000 80d9ca0c 9fc33da4
4  kernel: [10712.316341][1]        00000101 8060f898 00000082 80582378 00000001 00000320 810d903a 9fc33d00
4  kernel: [10712.316445][1]        ...
3  kernel: [10712.316763][1]Classified pointer on stack:
3  kernel: [10712.316830][1]80582318 vprintk_emit+0x53c/0x578
3  kernel: [10712.319466][1]9fca406c [slab: type:task_struct size:1568 start:0x9fca3d40+0x32c]
3  kernel: [10712.320225][1]80582378 vprintk+0x24/0x30
3  kernel: [10712.320914][1]8060f898 printk+0x24/0x30
3  kernel: [10712.321167][1]80582378 vprintk+0x24/0x30
3  kernel: [10712.322294][1]8087fdd4 dump_stack+0x94/0xd0
3  kernel: [10712.322544][1]Call Trace:
3  kernel: [10712.322640][1][<8050ca6c>] 0x8050ca6c show_stack+0x54/0x88
3  kernel: [10712.322724][1][<8087fdd4>] 0x8087fdd4 dump_stack+0x94/0xd0
3  kernel: [10712.322805][1][<8052e514>] 0x8052e514 __warn+0xe4/0x118
3  kernel: [10712.322880][1][<8052e5d8>] 0x8052e5d8 warn_slowpath_null+0x1c/0x34
3  kernel: [10712.322971][1][<80a76bf0>] 0x80a76bf0 lro_timer_fn+0x28/0x48
3  kernel: [10712.323082][1][<80598eb4>] 0x80598eb4 call_timer_fn+0xc8/0x1c8
3  kernel: [10712.323195][1][<80599154>] 0x80599154 expire_timers+0x1a0/0x1e4
3  kernel: [10712.323307][1][<80599244>] 0x80599244 run_timer_softirq+0xac/0x208
3  kernel: [10712.323404][1][<8053513c>] 0x8053513c __do_softirq+0x268/0x564
3  kernel: [10712.323478][1][<8053574c>] 0x8053574c irq_exit+0x9c/0xfc
3  kernel: [10712.323565][1][<808c4484>] 0x808c4484 gic_shared_irq_vi3_dispatch+0x148/0x190
3  kernel: [10712.323645][1][<80506144>] 0x80506144 except_vec_vi_end+0xf0/0xf8
3  kernel: [10712.323716][1][<80508230>] 0x80508230 r4k_wait_irqoff+0x34/0x40
3  kernel: [10712.323815][1][<8057ae98>] 0x8057ae98 cpu_startup_entry+0x108/0x180
4  kernel: [10712.323935][1]---[ end trace 3abb32ff0562ef1b ]---
 
Zuletzt bearbeitet:
Noch mal zum "Kontext" nachgefragt ... das ist also ein "Minimal-Image", das auf einer Box läuft, wo das Timeout für den System-Start auf sechs Minuten gesetzt wurde? Und die (es ist nicht die von @JokerGermany, sondern irgendeine andere von jemandem, der das jetzt testen will) stürzt danach dann mit dem Watchdog-Timeout im "untrustedd" ab? Soweit richtig?

Wenn ja - stürzt die denn dann auch erst an dieser Stelle ab, wenn man den Start-Watchdog nicht verlängert? Was passiert, wenn man diese Box jetzt auf die Werkseinstellungen zurücksetzt, damit man sicher sein kann, daß der "untrustedd" nicht wegen irgendwelcher Artefakte in den Einstellungen stirbt? Denn wenn das auch mit den Werkseinstellungen passiert bei einem Freetz-Image, aber bei der originalen Firmware nicht, müßte es ja irgendeine Änderung seitens Freetz(-NG) sein, die das bewirkt.

Ich habe das mit den Watchdog-Handles jetzt mal auf einer 7490 angesehen - der erste Prozess mit einem Handle ist der "supervisor" selbst. Leider kommt nach dem Initialisieren der Systemüberwachung für den Start wohl kein weiteres Handle dazu und man findet die Infos wohl doch nur in der "dmesg"-Ausgabe, wo für den Start etwas wie:
Rich (BBCode):
[   ss.nnnnn] AVM_WATCHDOG: System Init Ueberwachung nnn Sekunden
und für das Ende dann:
Rich (BBCode):
[   ss.nnnnn] AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (nnn s noch verfuegbar)
stehen sollte. Dieser "init"-Watchdog wird wohl doch gesondert im wdt-Treiber behandelt und taucht in der Liste im procfs nicht auf - daher kann man dort auch nicht ermitteln, ob der nun deaktiviert wurde und wann das war. Dazu muß man in die "dmesg"-Ausgabe schauen.

Bei der 7490 war das - nebenbei bemerkt - bei Sekunde 77 vorbei - obwohl der am Beginn auf 240 Sekunden gesetzt wurde (176 Sekunden waren noch übrig). So etwas müßte sich ja (wenn die Box nicht wegen des "init"-Watchdogs abstürzt) auch in der Ausgabe bei der 7590 finden lassen, sofern der "supervisor" sich dazu entschließen kann, den Watchdog zu beenden - ich rate mal, daß das von einem:
Rich (BBCode):
[Supervisor] Info: all Services loaded.
begleitet ist auf "/dev/console". Unmittelbar davor kommt bei mir (wie gesagt, eine 7490 zum Test) noch der Start des "voipkpid.service" - aber selbstverständlich gehen alle möglichen asynchronen Aktivitäten parallel dazu noch weiter (USB-Mounts, WLAN-Suchen, etc.).

Eigentlich passiert ja (in der Theorie zumindest) rein gar nichts von der Freetz-Seite, wenn man den Mod mit dem "emergency off" (ds_off=y) abschaltet ... interessant wäre es halt, ob dann auch der Start-Watchdog (bei kleinerem Wert für das Timeout) beendet wird, nur ist es schwerer, da an die "dmesg"-Ausgabe zu gelangen.

Wobei ich bei diesem "emergency off" ohnehin meine Zweifel habe im Moment (und nicht nur für NG, sondern auch für Freetz) ... ich finde einfach die Stelle nicht, wo jemals die Variable "ds_off" von den "kernel_args" in das Shell-Environment überführt wurde. Denkbar, daß das über den Init-Prozess aus "/proc/cmdline" ins Environment exportiert wird - das muß ich mir erst noch einmal genau ansehen und vor allem auch, ob das beim "supervisor" auch noch so ist (der wird ja seinerseits von "init" gestartet und sollte das damit auch erben).

Aber ich denke, daß ich dabei trotzdem noch ein Problem in NG gefunden habe ... schreibe ich gleich noch ein EDIT zu. Ich will den Teil bisher aber erst mal loswerden.

EDIT: OK, ist doch kein Problem in NG (jedenfalls nicht so, wie gedacht) - mir war doch glatt entgangen, daß Du den "debug.cfg"-Support dauerhaft entsorgt hast für "supervisor"-basierte Versionen und er auch danach nicht mehr angefaßt wurde - das findet sich auch nicht in NEWS, ich habe extra noch einmal nachgesehen. Ich weiß zwar nicht genau, warum Du das machst und dachte zuerst, das wäre nur eine zeitweilige Änderung, bis Du die notwendigen Patches dafür zusammen hast - aber so, wie es jetzt ist, stimmt's dann doch.

Nur daß eben für jemanden, der ein Update von 07.12 auf 07.2x macht, das Feature jetzt eigentlich "silently" abgeschaltet wird, oder irre ich mich da? Wenn ich mit einer 07.12-Konfiguration mit "FREETZ_RESTORE_DEBUG_CFG_SUPPORT=y" ein "make menuconfig" aufrufe und auf 07.2x umstelle, ist der Patch halt "weg" und ich merke nichts davon (außer ich prüfe die Liste sehr, sehr genau), sondern wundere mich hinterher nur, warum meine "debug.cfg" nicht mehr will.

Wie auch immer ... ich würde jetzt bei der Eingrenzung des Watchdog-Problems noch klären, warum der "untrustedd" sich verabschiedet. Wenn das nicht das System von @JokerGermany ist und er das mit AVM-Firmware nicht macht, muß es ja einen Unterschied geben. Dazu muß aber erst einmal klar sein, daß das - auch auf diesem Gerät und mit einer definierten AVM-Konfiguration, die möglichst kein Mesh o.ä. beinhaltet - mit der AVM-Firmware nicht auch passiert.

Es sind offenbar zwei Probleme, die sich halt in demselben Verhalten zeigen ... einmal schlägt der Start-Watchdog zu, wenn die Freetz-Initialisierung erfolgt und das sollte sich eben vom "supervisor" irgendwie entkoppeln lassen - notfalls auch durch komplett andere Änderungen, wo dann eben die "rc.mod" nicht per "dot command" eingelesen, sondern als gesonderte und "detached" Instanz gestartet wird. Denn ohne Freetz ist da ja auch bei der 7590 wohl noch massig Zeit übrig, wenn der Watchdog abgeschaltet wird in der originalen Firmware.

Das zweite Problem ist unter bestimmten, noch unklaren Umständen dann der "untrustedd" ... auch dessen Watchdog schlägt irgendwie zu, wenn er die Chance dazu erhält (und das System nicht schon vorher neu gestartet wurde vom Start-Watchdog). Hier wäre die Frage, warum er das macht und ob man das (als alternativen Workaround, der nicht gleich alle anderen Watchdogs auch killt) einfach auch verhindern kann, wenn man den gar nicht erst starten läßt oder ihn (vor dem Watchdog) wieder beendet. Die Frage wäre halt, welche Funktion man damit verliert ... ich habe den bisher noch nie wirklich in Aktion erlebt, was mich eben zu der Vermutung brachte, daß der irgendetwas mit dem Mesh zu tun haben müßte, was bei mir nicht genutzt wird. Daher auch die Bedingung oben, daß für weitere Tests erst mal kein Mesh aktiv sein sollte ... klappt das auch schon nicht und macht sich da schon das Fehlen des "untrustedd" bemerkbar (weil er gar nicht gestartet wurde oder schon wieder beendet ist), ist meine Theorie mit dem Zusammenhang zwischen Mesh und "untrustedd" auch hinfällig.

EDIT2:
Ja, der "init-start"-Watchdog ist tatsächlich gesondert behandelt (aus drivers/char/avm_new/include/avm/watchdog/watchdog.h):
Code:
  7 #define MAX_WDT_APPLS    63 /*--- letzte Position ist fuer init-Ueberwachung reserviert ---*/
- da wird also der letzte Eintrag in der Tabelle genutzt (das wäre dann Nr. 64 - der wird über "array[MAX_WDT_APPLS] adressiert) und bei der Anzeige über "/proc/avm/wdt" wird nur bis "< MAX_WDT_APPLS" iteriert:
Code:
1023         for (idx = 0; idx < MAX_WDT_APPLS; idx++) {
 
Zuletzt bearbeitet:
Die Box ist nicht zurückgesetzt, volles image wie ich es sonst auch nutze. Labor oder Downgrade mach ich mit der Box nicht, ein Update nur alle paar Wochen.

Ich habe jetzt mal den watchdog gelassen wie avm es beabsichtigt hat (nicht ausgeschaltet) und habe den untrustedd service & binary entfernt. Damit läuft die box
Code:
-  Nov 14 23:16:52 FREETZMOD: Startup finished.
2  Nov 14 23:16:52 kernel: [   92.532120][2]AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (49 s noch verfuegbar)

---

Du hättest besser nicht editiert sondern einen neuen Post gemacht. So muss ich doppelposten!

debug.cfg: Genau, gibt es schon länger nicht mehr. Hätte man in NEWS machen können, aber ich denk da nicht immer dran. Ich selbst brauch die debug.cfg nicht, bei AVM gibt es sie ja auch nicht mehr. Mit Freetz gibt es eh die rc.custom. Wenn jemand dafür einen Patch machen will, kann er das gerne tun... Du bist der erst der es vermisst
Es gibt viele Dinge die es nur bei bestimmten FOS oder Kernelverison gibt. Mir fallen da remove-wlan & remove-telefon ein. Wer's braucht solls sich darum kümmern

Ich glaub das untrustedd ist 1 Problem, nämlich dass der hängt und startup-done nicht meldet.
Dass er bei allen die anfangs "rebootloop" gemeldet hatten die Konvertierung fehlschlug glaube ich nicht, das sollte AVM spätestens mit 7.21 gefixt haben
Mir ist jetzt ohne den nichts aufgefallen was nicht geht

Den rcmod unabhängig vom Watchdog machen wäre gut. Wie du schriebst über die "tail"? Ich wollte noch testen wieviele Sekunden ein "kleines" Freetz für den Watchdog ausmacht.
 
Nein, das über "tail" war nur ein Vorschlag auf die Schnelle - das ist theoretisch viel zu früh.

Ich würde immer noch hingehen und in der "99-zzz-rcmod" den Start der "rc.mod" (https://github.com/Freetz-NG/freetz-ng/blob/master/patches/scripts/115-patch-ds_off.sh#L15) über ein "nohup" machen, so wie ich es für die "rc.user" in "modfs" mittlerweile auch mache: https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_rc_tail_sh#L50

Wichtig dabei ist, daß der Prozess für alle Standard-Dateihandles Ersatz kriegt und keines der Files vom Elternprozess verwendet wird, damit die geschlossen und abgeräumt werden können, wenn das (aufrufende) Skript beendet ist.

Daher würde ich das "tee" und das "sed" für die Anzeige auf "/dev/console" (woanders taucht das ja erst einmal ohnehin nicht auf) auch nicht gleich dort machen, sondern z.B. über ein (als gesonderter Prozess gestartetes) "tail -f" oder ähnliches. Wenn man das erst mal entkoppelt hat, kann man sich dann auch Gedanken machen, wie man die Ausgaben "schön" machen könnte - da arbeitet mittlerweile sogar AVM mit passenden ANSI-Sequenzen fürs Terminal, damit die Zeilen auch "ohne Suchen" auffallen.

Mit dem "nohup" kann dann der "rcmod.service" ja auch weiterhin mit "WantedBy=multi-user.target" daherkommen ... der muß halt nur nach dem "nohup" selbst fertig werden, damit die Rückmeldung beim "supervisor" erfolgt und der den Zustand des Service "notiert". Bei der Gelegenheit empfehle ich das Nachlesen, was "oneshot" und "RemainAfterExit" für Auswirkungen auf den "Zustand" des damit definierten Services haben - das wird u.a. dann wichtig, wenn es um die Frage geht, ob man so etwas ein zweites Mal starten kann (ohne es zuvor zu stoppen) oder nicht und was der "supervisor" als Zustand nach dem erfolgreichen Ende von "ExecStart" annehmen soll ... "active" oder "inactive".
 
Startdauer einer 7490
Code:
7490         "<2>Nov 15 00:26:50 kernel: [   16.030000] AVM_WATCHDOG: System Init Ueberwachung 240 Sekunden
7490         "<->Nov 15 00:27:01 FREETZMOD: Startup finished.
7490         "<2>Nov 15 00:27:01 kernel: [   80.600000][1]AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (175 s noch verfuegbar)

Entkoppeln von "mod" und dem Watchdogtimer wäre nicht schlecht. Mit diesen ganzen Pipes und Redirects kenne ich mich nicht so gut aus. Oder den Timer erhöhen damit es nciht zu problemen mit vielen Packages kommt. Ich hab das gestern so mit 7490 gestestet:
Code:
--- patches/scripts/115-systemd-services.sh
+++ patches/scripts/115-systemd-services.sh
@@ -19,6 +19,11 @@ Type=oneshot
 DefaultDependencies=no
 After=net.service modload.service
 [Install]
-WantedBy=multi-user.target
+EOF
+
+echo1 "extending tail"
+cat << 'EOF' >> "${FILESYSTEM_MOD_DIR}/etc/boot.d/core/tail"
+## start modification
+svctl start rcmod
 EOF
Dropbear und Syslog waren aber nicht verfügbar, auch nicht anpingbar. Aktuell ist keine Console angeschlossen

Den rcmod sollte man nicht mehrfach startet, das war aber schon immer so , dass "rc.mod load" von Hand mehrfach gestartet werden konnte.
Am besten wäre ein Service-Typ der einfach nur einen Befehl ausführt und nicht auf das eventuelle Ende wartet
 
Wie oben geschrieben ... ich würde versuchen, das gleich besser zu machen. Das mit der "tail" war nur ein erster Gedanke - die gehört zu einem anderen Target (der "debug.service" gehört zu "sysinit.target") und bisher dürften uns allen noch die genauen Ideen fehlen, was der "supervisor" mit den Abhängigkeiten und den verschiedenen Targets macht. Bei aller Ähnlichkeit der Konfigurationsdateien mit dem "systemd", weiß man ja nicht, was AVM da alles weggelassen hat von den Funktionen eines ausgewachsenen "systemd".

Ich hatte das für "modfs" eben so getestet, wie ich das oben verlinkt habe - auch eine 10 minütige Schleife mit jeweils einem "sleep 10" am Beginn des Inhalts der "rc.user" konnte nicht verhindern, daß nach diesen 10 Minuten dann der Rest der Kommandos in der "rc.user" noch abgearbeitet wurde ... und ich hatte dabei keine Probleme mit dem Watchdog beim Systemstart. Daher würde ich mich für den Test einer dauerhaften Lösung auch für Freetz auf diesen Ansatz zurückziehen und ihm zumindest in einem ersten Versuch die Chance geben, seine Tauglichkeit unter Beweis zu stellen oder eben das Gegenteil zu zeigen.

Das mit dem "auch nicht anpingbar" verstehe ich nicht ... bezieht sich das auf die Box generell oder auf den SSH- und den Syslog-Service?

Man muß wohl beim "supervisor" auch mächtig aufpassen, daß man nicht im unpassenden Moment einen Fehler zurückgibt. Manche der AVM-Dateien (in "/etc/boot.d") enthalten explizit ein "set -e" und testen nicht auf weitere Fehler bzw. "entschärfen" potentielle Fehler dann durch etwas wie: <cmd> || true, damit da ein positives Ende vermeldet wird - wenn das für die "tail" auch ein Problem sein sollte (ich müßte mir die Abläufe erst noch einmal genau ansehen), dann könnte ich mir zumindest eine Theorie zurechtbasteln, warum da nichts weiter gestartet wurde.

Mein Vorschlag bleibt: Vergiß das mit der "tail" (die ist zu früh), bleib beim Start durch die Abhängigkeit über "WantedBy" und ändere die "99-zzz-rcmod" so ab, daß die nur die "rc.mod" anstartet und dann sofort wieder zum "supervisor" zurückkehrt. Das sind halt ein paar mehr Änderungen, als ich sie jemandem empfehlen würde, der eine Fehlersuche starten will und erst mal klären muß, wo er was ändert, damit das am Ende auch im Image landet - aber sie sind nach meiner Ansicht nachhaltiger und plausibler.

Außerdem würde ich Dir für solche Fehlersuchen etwas empfehlen, was ich selbst dann immer verwende, wenn ich keine Serielle dran habe ... einfach einen gesonderten Service für eine Shell einbauen (den man notfalls auch erst wieder über die Kernel-Parameter aktivieren muß und der ansonsten gleich wieder endet), dann hat man zumindest noch einen Notzugang, wenn die "richtigen Modifikationen" aus irgendeinem Grund nicht wollen. Auch kann man in so einem Skript dann viele andere Optionen zusammenfassen ... wenn's schon sehr, sehr früh in der Initialisierung klemmt, kann es auch helfen, wenn man einige Protokolldaten aktiv von der Box aus auf ein anderes System schreibt.

Wie so eine "frühe Initialisierung" des Netzwerks aussehen muß, kann man sich in den Flash-Skripten von AVM ansehen - da wird (bei passendem Inhalt von "ptest", aber man kann das ja so anpassen, wie man es braucht) das Ergebnis des Flashens an einen Protokoll-Server gemeldet und das kann man natürlich mit "richtigen" Protokollen oder den Ausgaben irgendwelcher Kommandos für "trace points" auch machen - allerdings sollte man da "tftp" benutzen, weil das "psupportd_sendmsg" wohl einen speziellen Empfänger braucht. Das TFTP-Protokoll ist aber so simpel, daß man damit schon ohne große Unterstützung durch den Netzwerk-Stack des OS Daten durch die Gegend schieben kann - daher nutzen es ja auch viele Geräte für Konfigurationen und Updates.

Oder - wenn man ein "nc" (netcat) in der BusyBox hat - man leitet gleich die gesamte Protokollierung ins Netzwerk um, wie hier: https://github.com/PeterPawn/YourFritz/blob/master/autoupdate/run_update - es gibt viele Möglichkeiten, wie man nicht nur aus den Symptomen (nicht gestartete Services) darauf schließen kann, was da geht und was nicht geht - das senkt die Gefahr, daß man sich irrt und dann trotzdem mit Vollgas in die falsche Richtung kriecht.
 
Komplett nicht anpingbar, also über icmp das keine Ports kennt. Der Start hing wohl komplett.
Ich hab ja die 3 seriellen Consolen der 7490 angelötet, nur ist das Gehäuse momentan zu. So hatte ich auch die 2 aktuellen services erstellt
Ich baue das bei Gelegenheit wieder um. Glaubst du deshlab könnte der untrustedd crashen?
 
Glaubst du deshlab könnte der untrustedd crashen?
Warum jetzt genau? Weil da serielle Schnittstellen bestückt sind, an denen kein Terminal hängt? Glaube ich eher nicht - war bei @JokerGermany ja auch zu sehen und der hat sicherlich keine Lötarbeiten vorgenommen.

Aber wenn ein Start komplett hängt (da sollte ihn der "init"-Watchdog ja eigentlich erlösen) und das nur deshalb, weil der Freetz-Mod jetzt NICHT gestartet wird, ist das wohl eher ein Zeichen für einen Syntax-Fehler in den Änderungen oder einen Fehler in einer der aufgerufenen Skript-Dateien, als für einen Fehler in der Idee - oder das "svctl start" kommt eben doch deutlich zu früh. Man weiß ja - wie schon mal festgestellt - nicht genau, was AVM da alles in den "supervisor" übernommen hat (wirklich alles kann es kaum sein, "systemd" als Paket ist deutlich, deutlich größer) und man wird bei AVM wohl eher nicht damit gerechnet haben (oder es zumindest nicht wirklich berücksichtigen), daß sich andere da an den Startprozess anhängen könnten.

Mach doch wirklich mal den Test mit einem "nohup" in der "99-zzz-rcmod" ... und vergiß nicht, vorher irgendetwas zu protokollieren, daß das jetzt losgehen soll bzw. hinterher die PID des mit "nohup" gestarteten Prozesses (der muß natürlich parallel arbeiten, daher das "&" am Ende) anzusagen (und sei es erst einmal nur zum Testen), damit man weiß, wo man suchen muß bzw. welchen Pfad in "/proc/<pid>/*" man benutzen müßte, um sich vom Zustand dieses Prozesses zu überzeugen. Dann weiß man wenigstens, daß das System bis dort kommt (notfalls nimmt man eben "led-ctrl" und blinzelt dem Benutzer mit irgendeiner LED zu, die zu diesem Zeitpunkt sonst nicht benutzt wäre) und nicht schon vorher irgendwo verreckt ist.
 
Ob du meinst dass es einen Zusammenhang vom untrusted-Problem & der Art wie Freetz gestartet wird vermutest. Ich glaube dass das 2 unabhängige Dinge sind.
Was ich für die "tail" änderte ist im diff oben, das sollte genau so sein wie es dein Idee war.

--

vorher
Code:
7490         "<->Nov 15 00:27:01 FREETZMOD: Startup finished.
7490         "<2>Nov 15 00:27:01 kernel: [   80.600000][1]AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (175 s noch verfuegbar)


Code:
--- patches/scripts/115-patch-ds_off.sh
+++ patches/scripts/115-patch-ds_off.sh
@@ -12,7 +12,7 @@ fi

# Emergency stop switch for execution of Freetz as a whole
[ ! -e "$dsfile" ] && echo '#!/bin/sh' > "$dsfile" && echo1 "adding ${dsfile#$FILESYSTEM_MOD_DIR}"
-echo '[ "$ds_off" == "y" ] || . /etc/init.d/rc.mod 2>&1 | tee /var/log/mod.log | sed "s/^/[FREETZ] RCMOD: /g"' >> "$dsfile"
+echo '/bin/busybox nohup /bin/sh /etc/init.d/rc.mod >/var/log/mod.log 2>&1 </dev/null &' >> "$dsfile"
chmod +x "$dsfile"

# Emergency stop switch for execution of debug.cfg

nachher
Code:
7490         "<2>Nov 15 17:38:58 kernel: [   68.440000][0]AVM_WATCHDOG: System Init Ueberwachung abgeschlossen (188 s noch verfuegbar)
7490         "<->Nov 15 17:39:06 FREETZMOD: Startup finished.

Das hat jetzt den Nachteil dass die Console nichts mehr dazu ausgibt und ds_off nicht mehr geht. Dafür werden 10-15 Sekunden für den Watchdog gespart
 
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.