[Problem] Freetz Trunk Rev. 8310 - Reboot-Problem mit Fritzbox 7390 FW 05.05.

aladin_dd · 25 Dez 2011

Hallo,

ich hab Zugriff auf die Box über die serielle Konsole.

die Ausgabe beim Reboot bleibt hängen und sieht so aus:

Code:

BusyBox v1.19.3 (2011-12-24 22:59:15 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.


root@fritz:/var/mod/root# reboot
SHUTDOWN: initiated
root@fritz:/var/mod/root# SHUTDOWN: executing /etc/init.d/rc.mod stop
Stopping all packages:
inetd: Stopping inetd ... not running.
authorized-keys: 
dropbear: Stopping dropbear SSH server ... done.
Usage: /etc/init.d/rc.avm-firewall [load|unload|save]
avm-firewall: 
onlinechanged: 
Usage: /etc/init.d/rc.opendd [load|unload|run|config|cron]
opendd: 
rsync: Stopping rsync ... not running.
spindown: Stopping spindown ... not running.
crond: Stopping crond ... not running.
telnetd: Stopping AVM telnetd ... not running.
webcfg: Stopping Freetz webinterface ... done.
dsld: Stopping AVM dsld ... done.
multid: Stopping AVM multid ... done.
Stopping all packages finished.
SHUTDOWN: executing /var/post_install
stopping USB-Subsystem ..
killall: printserv: no process killed
rmmod: can't unload 'vfat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'fat': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_cp437': unknown symbol in module, or unknown parameter
rmmod: can't unload 'nls_iso8859_1': unknown symbol in module, or unknown parameter
rmmod: can't unload 'sd_mod': unknown symbol in module, or unknown parameter
rmmod: can't unload 'ext2': unknown symbol in module, or unknown parameter
rmmod: can't unload 'usb_storage': unknown symbol in module, or unknown parameter
rmmod: can't unload 'scsi_mod': unknown symbol in module, or unknown parameter
OHCI USB 1.1 Host stopped
cat: can't open '/proc/bus/usb/devices': No such file or directory
EHCI USB 2.0 Host stopped
cat: can't open '/proc/bus/usb/devices': No such file or directory
ls: /var/USB-proc-bus-usb-*: No such file or directory
USB-Subsystem .. stoped
unmounting '/var/media/ftp/*' ..
[2988]++ ++ do internalflash 'prepare unmount'... ++ ++
[2988]++ ++ ...done ++ ++
unmounting '/var/dev/nand' ..
unload dsl and dependend driver ..
killall: can't kill pid 746: No such process
killall: can't kill pid 747: No such process
killall: can't kill pid 748: No such process

ps gibt das aus:

Code:

root@fritz:/var/mod/root# ps
  PID USER       VSZ STAT COMMAND
    1 root      1140 S    init
    2 root         0 SW<  [kthreadd]
    3 root         0 RWoftirqd/0]
    4 root         0 SW<  [watchdog/0]
    5 root         0 SW<  [events/0]
    6 root         0 SW<  [khelper]
    7 root         0 SW<  [CPMAC workqueue]
    8 root         0 SW<  [kblockd/0]
   10 root         0 SW   [pdflush]
   11 root         0 SW<  [kswapd0]
   12 root         0 SW<  [aio/0]
   13 root         0 SW<  [nfsiod]
   21 root         0 SWN  [avmdebug]
   22 root         0 SW   [pm_info]
   23 root         0 SW<  [mtdblockd]
   26 root0 SW<  [rpciod/0]
   27 root         0 SW   [tffsd_mtd_0]
   86 root         0 SW   [cleanup_timer_f]
  207 root         0 SW   [pdflush]
  210 root         0 SW<  [capi_oslib]
  211 root         0 SW<  [capi_oslib/0]
  212 root         0 SW   [capitransp]
  215 root         0 SW<  [avm_dect_thread]
  216 root         0 SW   [ksock tcp worke]
  217 root         0 SW   [ksock tcp serve]
  425 root      1012 S <  /sbin/udevd --daemon
  454 root         0 SW<  [khubd]
  503 root      1012 S <  /sbi--daemon
  504 root      3836 S    /bin/configd
  528 root      3844 S    /bin/configd
  533 root      5020 S    /usr/bin/vdsld ats
  590 root      5020 S    /usr/bin/vdsld ats
  591 root      5020 S    /usr/bin/vdsld ats
  592 root      5020 S    /usr/bin/vdsld ats
  593 root      5020 S    /usr/bin/vdsld ats
  594 root      5020 S    /usr/bin/vdsld ats
  595 root      50usr/bin/vdsld ats
  596 root      5020 S    /usr/bin/vdsld ats
  602 root      5020 S    /usr/bin/vdsld ats
  699 root         0 SWN  [dectuart_route]
  706 root      9436 S    /usr/bin/avm/ctlmgr
 1279 root      5032 S    telefon a127.0.0.1
 1292 root      3664 S    pbd
 1293 root      3664 S    pbd
 1294 root      3664 S    pbd
 1295 root      3664 S    pbd
 1296 root      3664 S    pbd
 1364 root      5032 S    telefon a127.0.0.1
 1365 root      5032 S    telefon a127.0.0.1
 1815 root       816 S    /bin/run_clock -c /dev/tffs -d
 2017 root      1128 S    {busybox} syslogd -L -O /var/tmp/messages.log
 2019 root      1132 S    /sbin/klogd -c 5
 2471 root      1148 S    -/bin/sh797 root      1132 S    /bin/sh -c /etc/inittab.shutdown
 2798 root      1136 S    {inittab.shutdow} /bin/sh /etc/inittab.shutdown
 2988 root      1148 S    {busybox} ash /var/post_install
 3050 root      1012 S <  /sbin/udevd --daemon
 3643 root      ybox} ash /etc/init.d/rc.dsl.sh stop
 6992 root      1124 S    {busybox} sleep 1
 6993 root      1136 R    {busybox} ps

Nach meinem Verständnis bleibt folgendes Script hängen:

Code:

/etc/init.d/rc.dsl.sh stop

Nachdem ich mit

Code:

killall -9 ctlmgr
killall -9 telefon
killall -9 pbd

die 3 Prozesse abgeschossen habe, rebootet die Box weiter.

Die Box hängt noch nicht an einem DSL-Anschluss und hat noch keine Telefonie-Daten.

Hat jemand eine Idee, warum die Prozesse sich beim reboot nicht beenden?
Kann ich noch andere Daten zur Verfügung stellen?

Viele Grüße und noch schöne Feiertage...

astrapi · 25 Dez 2011

noch keine Lösung, aber siehe http://www.ip-phone-forum.de/showthread.php?t=243104

RalfFriedl · 26 Dez 2011

aladin_dd schrieb:
Nachdem ich mit

Code:

killall -9 ctlmgr killall -9 telefon killall -9 pbd

die 3 Prozesse abgeschossen habe, rebootet die Box weiter.

Im Zweifelsfall liegt es nur an einem von den drei Prozessen. Finde erstmal heraus, welcher es ist.

Suchiman · 26 Dez 2011

Mein Verdachtsfall erhärtet sich, es ist der Toolchain Compiler Upgrade auf GCC 4.6.2 das diese Probleme hervorruft, das hatte ich damals getestet und auch ein Ticket dazu eröffnet mit dieser Problematik, eine Lösung gibs bisher noch nicht, sicherlich irgendeine der Optimierungen denn die Binaries werden auch ein ganzes stück kleiner durch den compiler umstieg siehe Changeset 8305

aladin_dd · 26 Dez 2011

RalfFriedl schrieb:
Im Zweifelsfall liegt es nur an einem von den drei Prozessen. Finde erstmal heraus, welcher es ist.

Hab die Prozesse in unterschiedlicher Reihenfolge gekillt.
Weiter ging es erst, wenn alle 3 gekillt waren...

Code:

...
stop_dsl() {
## set
## we cant call rc.net cause when called for post_install (init process) all out
## CONFIG_-Values are not set!
## /etc/init.d/rc.net shutdown
## assume zombies as dead in termXXX (important when called from init process)
ZOMBIES_ARE_DEAD=yes
## termavmwait 999 usermand avmike dsld voipd igdd websrv multid ctlmgr
rm /var/rfcntlsock 2> /dev/null
termavmwait 999 usermand avmike voipd ctlmgr
termavmwait 999 dsld
termwait 999 telefon pbd faxd minid dtrace
termwait 999 cat
rmmod rfcntl
rmmod capi_codec
rmmod isdn_fbox_fon5
rmmod isdn_fbox_fon4
rmmod isdn_fbox_fon3
rmmod isdn_fbox_fon2
rmmod isdn_fbox_fon
## some more
rmmod ulpcmlink
rmmod dect_io
rmmod avm_dect
rmmod pcmlink
## 'rmmod userman' is for compatibility
rmmod userman
rmmod userman_mod
rmmod kdsldmod
rmmod ubik2
rmmod tiatm
ps
lsmod
}
...

Laut Script wird ja erst ctlmgr dann telefon und pbd beendet.

Kann aber gern noch ein paar Experimente machen.
Brauche dann aber einen Hinweis, was ich testen soll.

Noch habe ich die Box hier mit seriellem Anschluss.

aladin_dd · 26 Dez 2011

Suchiman schrieb:
Mein Verdachtsfall erhärtet sich, es ist der Toolchain Compiler Upgrade auf GCC 4.6.2 das diese Probleme hervorruft, das hatte ich damals getestet und auch ein Ticket dazu eröffnet mit dieser Problematik, eine Lösung gibs bisher noch nicht, sicherlich irgendeine der Optimierungen denn die Binaries werden auch ein ganzes stück kleiner durch den compiler umstieg siehe Changeset 8305

Ok, hab gerade freetz in Rev. 8304 gebaut und damit rebootet die Box.
Dies würde Deinen Verdacht bestätigen...

dileks · 26 Dez 2011

aladin_dd schrieb:
Ok, hab gerade freetz in Rev. 8304 gebaut und damit rebootet die Box.
Dies würde Deinen Verdacht bestätigen...

Typo? Ist r8304 GOOD? Sodann wäre r8305 BAD!

Bei Verwendung der Download-Toolchain natürlich!
Besteht das Problem auch Im Falle Build-Toolchain?

EDIT: Download-Toolchain VS. Build-Toolchain?

dileks · 26 Dez 2011

Just FYI: Im Ticket #1555 gibt es eine Menge Sachen mit denen Ihr spielen und somit das Problem evtl. eingrenzen könnt.

[1] http://freetz.org/ticket/1555

aladin_dd · 26 Dez 2011

dileks schrieb:
Just FYI: Im Ticket #1555 gibt es eine Menge Sachen mit denen Ihr spielen und somit das Problem evtl. eingrenzen könnt.

[1] http://freetz.org/ticket/1555

Mit -O0 -O1 -O2 -O3 und Download-Toolchain keine anderes Verhalten.
Hängt immer noch beim Reboot.

Da das Problem mit der Build-Toolchain und gcc-4.6.x schon länger bekannt ist,
würde ich es mir erstmal verkneifen alle möglichen Varianten durch zu probieren.

Wenn ich konkret etwas testen kann, dann gerne...

dileks · 26 Dez 2011

Warum baust du die Target-Toolchain nicht selber? Gerade wenn du vermutest, es handele sich um ein Problem in der DL-Toolchain?

aladin_dd · 26 Dez 2011

dileks schrieb:
Warum baust du die Target-Toolchain nicht selber? Gerade wenn du vermutest, es handele sich um ein Problem in der DL-Toolchain?

Ich vermute es ja gar nicht, hab da nicht so die Erfahrung das ich etwas vermuten könnte... ;-)

OK, ich baue es einmal selber.
Soll ich etwas speziell noch einstellen?

dileks · 26 Dez 2011

aladin_dd schrieb:
Da das Problem mit der Build-Toolchain und gcc-4.6.x schon länger bekannt ist,
würde ich es mir erstmal verkneifen alle möglichen Varianten durch zu probieren.

Danke für deine Mühe, aber Toolchain-Issues sind generell schwer zu triggern.
BTW, welche Target-Toolchain-Matrix verwendest du? gcc-4.5.3 als Target-Compiler ist OK?

Wenn ich konkret etwas testen kann, dann gerne...

Ja, konkret: Build-Toolchain (selber bauen!) mit FREETZ_TARGET_TOOLCHAIN_AVM_COMPATIBLE=y aktiviert. Am besten zusammen mit -O0 OptLevel.

Es kann gut sein, die Download-Toolchain ist BORKED. er13 will sich das Morgen näher anschauen.

aladin_dd · 26 Dez 2011

So, hab jetzt einmal mit gcc-4.5.3 und gcc-4.6.2 die Build-Toolchain gebaut

dileks schrieb:
gcc-4.5.3 als Target-Compiler ist OK?

Mit gcc-4.5.3 kein reboot-Problem.

dileks schrieb:
Ja, konkret: Build-Toolchain (selber bauen!) mit FREETZ_TARGET_TOOLCHAIN_AVM_COMPATIBLE=y aktiviert. Am besten zusammen mit -O0 OptLevel.

Mit gcc-4.6.2 und -O0 weiterhin reboot-Problem.

Code:

FREETZ_TARGET_TOOLCHAIN_AVM_COMPATIBLE=y

Kann man ja gar nicht auswählen, da man FREETZ_UCLIBC_0_9_28_BASED_BOX bzw. FREETZ_UCLIBC_0_9_29_BASED_BOX nicht auswählen kann...

Code:

Symbol: FREETZ_TARGET_TOOLCHAIN_AVM_COMPATIBLE [=n]                                                                        │   
  │ Type  : boolean                                                                                                            │   
  │ Prompt: Create toolchain compatible with original firmware                                                                 │   
  │   Defined at Config.in.cache:38999                                                                                         │   
  │   Depends on: FREETZ_BUILD_TOOLCHAIN [=y] && (FREETZ_UCLIBC_0_9_28_BASED_BOX [=n] || FREETZ_UCLIBC_0_9_29_BASED_BOX [=n])  │   
  │   Location:                                                                                                                │   
  │     -> Advanced options                                                                                                    │   
  │       -> Toolchain options

Gibt ja nur 0.9.31.1 und 0.9.32 im Angebot.
Oder muss ich noch etwas anderes einstellen?

dileks · 26 Dez 2011

aladin_dd schrieb:
So, hab jetzt einmal mit gcc-4.5.3 und gcc-4.6.2 die Build-Toolchain gebaut

Mit gcc-4.5.3 kein reboot-Problem.
Mit gcc-4.6.2 und -O0 weiterhin reboot-Problem.

Danke für deine Mühe, sieht nach einem gcc-4.6 Problem aus.

Code:
Code:

FREETZ_TARGET_TOOLCHAIN_AVM_COMPATIBLE=y

Kann man ja gar nicht auswählen, da man FREETZ_UCLIBC_0_9_28_BASED_BOX bzw. FREETZ_UCLIBC_0_9_29_BASED_BOX nicht auswählen kann...

Ich erinnerte mich dunkel an diese Freetz-Option, mir ist leider entgangen, dass es nur für 0.9.2x-based Boxes auswählbar ist.

ATM, leider keine weiteren Ideen.

Ballzauber · 27 Dez 2011

Ganz kurze Zwischenfrage hab ich das richtig mit bekommen friz!load funktioniert doch mit der 7390 und der fw 84.05.05 .... wenn ja was muss man dann beachten....oder läuft es damit problemlos und ich kanns einfach so installieren !?

RalfFriedl · 27 Dez 2011

Hat das irgend einen Bezug zu dem Thema hier?

er13 · 8 Jan 2012

dileks schrieb:
sieht nach einem gcc-4.6 Problem aus.

ist es auch gewesen, fixed in r8366 (self-built toolchain) & r8374 (download-toolchain)

dileks · 10 Jan 2012

Frohes neues 2012!
Aus verschieden Gründen war ich nicht am PC gewesen über Xmas bis heute.

Super, dass das "Suchiman Problem" [0] gelöst ist!
Wenn der Patch [1] noch nicht im gcc-4_6-branch [3] ist, sollten wir Upstream bitten, diesen aufzunehmen, sodass er auch in gcc-4.6.3 landet.
@er13: Willst du eine Email schreiben, soll ich?

[0] http://freetz.org/ticket/1555
[1] http://gcc.gnu.org/git/?p=gcc.git;h=e54aa8a4b85c7f1e8ea0dd233a65c1daa5c816cb
[2] http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gcc-4_6-branch

er13 · 10 Jan 2012

dileks schrieb:
@er13: Willst du eine Email schreiben, soll ich?
[1] http://gcc.gnu.org/git/?p=gcc.git;h=e54aa8a4b85c7f1e8ea0dd233a65c1daa5c816cb

ich hätte nichts dagegen, wenn Du diesen Teil übernehmen würdest. Ich würde direkt Paul Brook anschreiben (seine eMail kannst Du [1] entnehmen) und auf diesen Thread verweisen, er wird sich bestimmt noch erinnern können, um was es geht ;-)

Danke schon mal im voraus!

[Problem] Freetz Trunk Rev. 8310 - Reboot-Problem mit Fritzbox 7390 FW 05.05.

Neuer User

Anhänge

Mitglied

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

Neuer User

IPPF-Urgestein

Aktives Mitglied

Neuer User

Aktives Mitglied

Statistik des Forums