Freetz trunk / 7390: kein Reboot und kein weiteres Update mehr möglich

[olistudent]

@Oliver: Kannst du bitte mit dem getcons-Patch aufklären? Wie rum ist er nicht auswählbar? So rum, als ob er nicht da wäre oder so rum, dass er immer aktiviert ist? Warum ist getcons nun weg?

Ja, weil er im menuconfig deaktiviert ist. Zu den Hintergründen gibt es ein Ticket.
getcons wird gelöscht und setconsole wird derzeit nicht aufgerufen. Die Konsole-Ausgaben werden also momentan nicht umgelenkt, außer man ruft selbst setconsole auf.

Gruß
Oliver

 

[hermann72pb]

@Ralf: Das heißt, wir drehen uns ein bisschen im Kreis und wissen zwar, was da ungefähr passiert, wissen aber nicht warum es erst jetzt auftritt und warum es nur bei bestimmten Boxen auftritt.
@Oliver: Genau dazu habe ich eine leise Vermutung, dass es jetzt auf jeden Fall etwas anders behandelt wird, als es früher war. Es mag ja sein, dass wir jetzt im Schnitt besser liegen als vorher und es mag sein, dass man getcons-Patch gar nicht benötigt. Man sollte aber nicht vergessen, dass 7170 noch eine 80-ger Firmware hat und es könnte schon in diesem Zusammenhang irgendwo Ecken geben, wo es anschließend hängt.

Es haben für mich also mehr oder weniger drei Richtungen rauskristaliesiert, wo man weiter schauen sollte:

1. FREETZMOUNT und libmodmount.sh. Man sollte versuchen ein Image OHNE FREETZMOUNT für eine 7170 zu bauen.
2. Wegoptimieren vom getcons-Patch. Es wäre interessant diesen Patch wenigstens experimentell in irgendeiner Form für 7170 reinzunehmen, um Auswirkungen zu testen.
3. Busybox 1.18. Irgendwas ist da anders als vorher. Vielleicht alte bisybox nehmen, mit mount -o bind drübermounten und dann reseten?

Wie gesagt, ich bin momentan auf einer anderen Baustelle ziemlich beschäftigt und folge und höre euch leider nur mental zu. Mal sehen, vielleicht komme ich im Laufe des Tages doch zu etwas selbst auszutesten.

MfG

 

[olistudent]

Zu Punkt 2) Wie wäre es mit einem "setconsole" vor dem "reboot"?

Gruß
Oliver

 

[RalfFriedl]

setconsole vor dem Reboot würde nur den Effekt von einem setconsole beim Login rückgängig machen. Da wir im Moment kein setconsole beim Login machen und das Problem auch auftritt, wenn man sich vorher gar nicht angemeldet hat, und Schreiben auf die Konsole auch nach erfolgter Abmeldung möglich ist, glaube ich nicht, daß das etwas bringt.

Tritt das Problem bei jemandem auf, der eine serielle Konsole angeschlossen hat?

 

[ahorn]

hallo,

ich habe mit 6466 trunk, 7390 und 04.89 leider das reboot problem auch mit dem patch 110-inittab. der reboot funktioniert, wenn ich meinen usb drucker (brother hl5240), welcher über ein aktives verlängerungskabel an der box hängt, abziehe. das usb-verlängerungskabel wird laut lsusb auch als usbhub vom system gewertet. weiterhin habe ich eine telefonanlage über ein pl2303 ser2usb am usb, welche per fernanschluß freigegeben ist. dieser eingesteckt beeinträchtigt nicht den reboot.

achja: ich habe in freetz lediglich openvpn eingebaut.

grüße

 

[hermann72pb]

So wie es aussieht, hast du ein Hardwareproblem. Das hat mit dem eigentlichen thema hier nicht zu tun, ich hatte mich aber dazu hier mindestens 3-4 Mal ausgelassen. Such einfach nach "Gleichtatktstörungen" "USB" "Schaltnetzteil", dann landest du bei meinen Äußerungen dazu. In 99% der Fälle hat es sich damals bestätigt. Soll heißen: Es sind bis jetzt keine USB-Treiber-bedingte Verhalten dieser Weise bekannt.

MfG

 

[Toadie]

Keine Ahnung, ob Ihr mit der folgenden Info 'was anfangen könnt, ich poste sie aber trotzdem 'mal:

ein (aus SuSE-Linux-Sourcen zusammengabautes) showconsole im post_install gibt beim reboot folgendes aus:

/dev/ttyS0

ein anschliesendes echo "Test" > /dev/console blockiert dann genauso, wie ein echo "Test" > /dev/ttyS0

/dev/console scheint von Anfang an per cmd-Line auf /dev/ttyS0 umgeleitet zu sein. Sobald der Buffer voll ist (2048 Zeichen ?), ist schluss. Ich probier demnächst mal wieder einen älteren Stand aus und schau' nach, wie's da war.

 

[RalfFriedl]

Es ist normal, daß die Konsole mit ttyS0 verbunden ist. Es ist abe rnicht normal, daß eine Ausgabe auf ttyS0 blockiert. Die Box würde sonst erst gar nicht hochfahren. Bleibt die Frage, was ttyS0 durcheinander bringen kann.

Was sagt denn stty?

# stty -a < /dev/console 
speed 38400 baud;stty: standard input

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

 

[ahorn]

MfG

Danke für die Info.

 

[JohnDoe42]

Hallo RalfFriedl,

mein stty sagt (mit .89 FW und Trunk Rev. 6466 ) das hier:

speed 9600 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Ich hab' das Image des aktuellen Trunks per Freetz-WebIF remote eingespielt (vorher eben die vorherige Trunk-Version ;-) ), Ergebnis: alles Bestens, nach drei Minuten war die Box wieder da.
Grüße,

JD.

 

[RalfFriedl]

Bis auf die Geschwindigkeit ist es das Gleiche wie bei mir. Allerdings tritt bei Dir auch kein Problem beim Reboot auf.

Interessant wäre, ob es auf Boxen, wo die Ausgabe nach ttyS0 blockiert, anders aussieht. Und ob die Angaben von /dev/console und von /dev/ttyS0 verschieden sind.

 

[JohnDoe42]

Hallo RalfFriedl,

/dev/ttyS0:

speed 9600 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Den Hänger beim Update/Reboot hatte ich zum ersten Mal auf einer 7170 FW mit der .86-Labor-FW und eine Trunk-Image (vermutlich Rev. 6415). Symptom hierbei war u.A. auch, das alle meine externalisierten Anwendungen im Freetz-WebIF verschwunden waren. Zwar lief die Box (inkl. den Standard-Diensten im Freetz-WebIF), aber die händisch angestoßenen Reboots (per Konsole-> Reboot, per Freetz-WebIF und per AVM-WebIF) liefen nur sporadisch. Ebenso war kein Downgrade auf die .80er-AVM-FW mehr möglich. Letztlich konnte mich nur ein Brechstangen-Downgrade auf die .80 per FTP-Uploader retten. Derzeit läuft auf der Box wieder ein stable-Image.
Grüße,

JD.

 

[RalfFriedl]

Und hast Du auch jetzt das Problem? Bleibt bei Dir die Box hängen, wenn Du etwas auf /dev/ttyS0 ausgibst?

 

[JohnDoe42]

Welche Box ? Die 7390/Devel 6466 oder die 7170/stable-1.1 ?
Irgendwas derart

cat MeineDatei > /dev/ttyS0

?
Grüße,

JD.

 

[Toadie]

7170:

29.04.80freetz-1.1-stable (funktionierendes Reboot):

/var/mod/root # stty -a < /dev/ttyS0
speed 38400 baud; rows 24; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal [COLOR="red"]-crtscts[/COLOR]
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

29.04.80freetz-devel-6417M (hängendes Reboot):

root@fritz:/var/mod/root# stty -a </dev/ttyS0
speed 38400 baud;stty: standard input

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal [COLOR="red"]crtscts[/COLOR]
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Das crtscts scheint sich tatsächlich geändert zu haben.
Da der tx-Counter nicht null ist, muss das Flag irgendwann nach dem Reboot gesetzt worden sein:

root@fritz:/var/mod/root# cat /proc/tty/driver/serial 
serinfo:1.0 driver revision:
0: uart:OHIO_UART port:00000000 irq:15 tx:1316 rx:0 RTS|DTR

Was mir auch noch aufgefallen ist, ist dass telnet bzw. busybox bei älteren Versionen eine Meldung:

BusyBox v1.12.4 (2011-01-07 23:11:08 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

[COLOR="red"]ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt[/COLOR]

ausgegeben haben. Die fehlt jetzt auch (könnte aber auch Absicht sein)

Übrigens konnte ich das crtscts Flag mit stty nicht zurücksetzen (weder beim 1.1-stable noch beim trunk) - Der Befehl hing dann einfach. Setzen ging dagegen beim stable.

Der Vollständigkeit halber:

root@fritz:/var/mod/root# cat /proc/cmdline 
 console=ttyS0,38400n8r

Na dann viel Spass beim Rätseln

 

[RalfFriedl]

Das ist doch schon mal etwas. Bei mir kann ich allerdings crtscts sowohl setzten als auch löschen. Wenn ich allerdings mit crtscts genug ttyS0 ausgebe, hängt die Ausgabe, und danach hängt auch stty.

Kannst Du feststellen, ob schon beim Ausführen der debug.cfg die Option gesetzt ist? Irgendwo muß die ja herkommen.

 

[Toadie]

Scheint schon beim Aufruf der debug.cfg gesetzt zu sein:

root@fritz:/var/mod/root# cat /var/result.txt 
speed 38400 baud;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal [COLOR="red"]crtscts[/COLOR]
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Damit wird das Debuggen wohl nicht gerade einfacher

Ich hab mal 'nen grep auf crtscts gemacht und bin im init von busybox fündig geworden:

static void set_sane_term(void)
{
...
/* added CRTSCTS to fix Debian bug 528560 */
	tty.c_cflag &= CBAUD | CBAUDEX | CSIZE | CSTOPB | PARENB | PARODD | CRTSCTS;
...l
}

Vielleicht wurde crtscts "zufällig" früher ausmaskiert, was jetzt nicht mehr passiert?
Warum tritt das Reboot-Problem dann nicht bei allen Boxen auf?
Warum kann ich ein gesetztes crtscts Flag nicht mehr rückgängig machen?

Bei Lust und Laune probier' ich morgen mal eine gepatchte BusyBox aus.

Gute Nacht

 

[RalfFriedl]

Sieht stark danach aus, als wäre das der Grund für das Problem.

 

[olistudent]

Ich hab die Änderung per Patch rückgängig gemacht. Bitte mal ausprobieren und berichten.

Gruß
Oliver

http://freetz.org/changeset/6468

 

[Toadie]

Hi Oliver,

das ist echter Optimismus (oder übersinnliche SW-Entwickler-Fähigkeiten):
den Patch schon erstellt, eingechecked und den Workaround entfernt, bevor sich der durchschnittliche Freetz User überhaupt über die Ursache im klaren ist

Ich hab den Patch für busy-box (revert_crtscts_fix.patch, bzw. changeset6468 ) gerade ausprobiert und meine Box (7170) kann jetzt wieder glücklich rebooten.

Das Ganze lag tatsächlich an dieser kleinen Änderung im init der busybox.

Gruß

Dirk