New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alfred stürzt ab #177

Closed
4ndr3 opened this Issue Aug 21, 2014 · 21 comments

Comments

Projects
None yet
7 participants
@4ndr3

4ndr3 commented Aug 21, 2014

Firmware: hamburg 0.5, Gluon v2014.3
alfred 2013.4.0
Gerät: TP-Link TL-WR842N/ND v1
Anbindung: WLAN mesh
Uptime (beim bemerken des Fehlers): 327h
dmesg & logread: nichts

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Aug 22, 2014

Member

Hmm, die Wahrscheinlichkeit ist groß, das das mit alfred 2014.3 im aktuellen master behoben ist...

Member

NeoRaider commented Aug 22, 2014

Hmm, die Wahrscheinlichkeit ist groß, das das mit alfred 2014.3 im aktuellen master behoben ist...

@tcatm

This comment has been minimized.

Show comment
Hide comment
@tcatm

tcatm Sep 11, 2014

Mitlerweile habe ich das Problem auch schon zweimal am Meuteknoten und einmal an FFHLWSHL01 (beide Lübeck) beobachtet. Beides 2014.3. In den Logs war auch nichts zu finden.

tcatm commented Sep 11, 2014

Mitlerweile habe ich das Problem auch schon zweimal am Meuteknoten und einmal an FFHLWSHL01 (beide Lübeck) beobachtet. Beides 2014.3. In den Logs war auch nichts zu finden.

@4ndr3

This comment has been minimized.

Show comment
Hide comment
@4ndr3

4ndr3 Sep 16, 2014

Auch auf Ubiquiti Nanostation M2 beobachtet. Gleiche firmware.

4ndr3 commented Sep 16, 2014

Auch auf Ubiquiti Nanostation M2 beobachtet. Gleiche firmware.

@NeoRaider NeoRaider added the bug label Oct 3, 2014

@NeoRaider NeoRaider added this to the 2014.4 milestone Oct 3, 2014

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Oct 3, 2014

Member

Das neue alfred liegt inzwischen auch im Branch 2014.3.x, den wir demnächst als 2014.3.1 releasen wollen. Ausgiebige Tests von dem Branch sind willkommen :)

(wenn man schon aktuelle Barrier-Breaker-basierte Firmwares gebaut hat, sollte man für 2014.3.x nen neuen Clone vom Gluon-Repo nehmen)

Member

NeoRaider commented Oct 3, 2014

Das neue alfred liegt inzwischen auch im Branch 2014.3.x, den wir demnächst als 2014.3.1 releasen wollen. Ausgiebige Tests von dem Branch sind willkommen :)

(wenn man schon aktuelle Barrier-Breaker-basierte Firmwares gebaut hat, sollte man für 2014.3.x nen neuen Clone vom Gluon-Repo nehmen)

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Oct 20, 2014

Member

Gluon 2014.3.1 ist draußen, es wäre höchst interessant, etwas Feedback zu bekommen, ob der Bug mit dem neuen alfred weiterhin auftritt.

Member

NeoRaider commented Oct 20, 2014

Gluon 2014.3.1 ist draußen, es wäre höchst interessant, etwas Feedback zu bekommen, ob der Bug mit dem neuen alfred weiterhin auftritt.

@poldy79

This comment has been minimized.

Show comment
Hide comment
@poldy79

poldy79 Oct 20, 2014

Contributor

bin gerade noch am bauen und scheitere aber grad am mtd-utils-1.4.5 - da
geht was beim "make" schief. Vielleicht liegt es an der v6 Konnektivität.

Checking out files from the git repository...
Cloning into 'mtd-utils-1.4.5'...
fatal: read error: Connection reset by peer
make[4]: ***
[/home/leonard/gluon_nightly/build/ar71xx-generic/openwrt/dl/mtd-utils-1.4.5.tar.gz]
Error 128

Viele Grüße

Leonard

Am 21. Oktober 2014 00:06 schrieb NeoRaider notifications@github.com:

Gluon 2014.3.1 ist draußen, es wäre höchst interessant, etwas Feedback zu
bekommen, ob der Bug mit dem neuen alfred weiterhin auftritt.


Reply to this email directly or view it on GitHub
#177 (comment)
.

Contributor

poldy79 commented Oct 20, 2014

bin gerade noch am bauen und scheitere aber grad am mtd-utils-1.4.5 - da
geht was beim "make" schief. Vielleicht liegt es an der v6 Konnektivität.

Checking out files from the git repository...
Cloning into 'mtd-utils-1.4.5'...
fatal: read error: Connection reset by peer
make[4]: ***
[/home/leonard/gluon_nightly/build/ar71xx-generic/openwrt/dl/mtd-utils-1.4.5.tar.gz]
Error 128

Viele Grüße

Leonard

Am 21. Oktober 2014 00:06 schrieb NeoRaider notifications@github.com:

Gluon 2014.3.1 ist draußen, es wäre höchst interessant, etwas Feedback zu
bekommen, ob der Bug mit dem neuen alfred weiterhin auftritt.


Reply to this email directly or view it on GitHub
#177 (comment)
.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Oct 20, 2014

Member

@poldy79: Joa, git.infradead.org ist gerade tot. Als Workaround kann man manuell https://downloads.openwrt.org/sources/mtd-utils-1.4.5.tar.gz nach openwrt/dl werfen.

Member

NeoRaider commented Oct 20, 2014

@poldy79: Joa, git.infradead.org ist gerade tot. Als Workaround kann man manuell https://downloads.openwrt.org/sources/mtd-utils-1.4.5.tar.gz nach openwrt/dl werfen.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Nov 12, 2014

Member

Hmm, ich hoffe mal, "no news is good news", umd mit 2014.3.1 tritt der Bug wirklich nicht mehr (oder deutlich seltener) auf? Oder hat bisher noch kaum jemand 2014.3.1 auf einer nennenswerten Menge Nodes ausgerollt?

Member

NeoRaider commented Nov 12, 2014

Hmm, ich hoffe mal, "no news is good news", umd mit 2014.3.1 tritt der Bug wirklich nicht mehr (oder deutlich seltener) auf? Oder hat bisher noch kaum jemand 2014.3.1 auf einer nennenswerten Menge Nodes ausgerollt?

@4ndr3

This comment has been minimized.

Show comment
Hide comment
@4ndr3

4ndr3 Nov 13, 2014

Auf Grund der noch häufigeren Neustarts bei 2014.3.1, haben wir es in HH nicht ausgerollt. Es läuft daher nur auf 5 Testgeräten. Ob dieser bug damit behoben ist, kann also nicht zuverlässig gesagt werden.

4ndr3 commented Nov 13, 2014

Auf Grund der noch häufigeren Neustarts bei 2014.3.1, haben wir es in HH nicht ausgerollt. Es läuft daher nur auf 5 Testgeräten. Ob dieser bug damit behoben ist, kann also nicht zuverlässig gesagt werden.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Nov 14, 2014

Member

Hier in Lübeck haben sich auf unseren 10 Testknoten die häufigen Neustarts nach ein paar Tagen normalisiert und die Knoten halten jetzt wieder Uptimes im Bereich von einigen Tagen bis über 3 Wochen.

Ich werde mal untersuchen, ob die Stabilitätsprobleme vielleicht mit dem neuen Autoupdater zusammenhängen...

Member

NeoRaider commented Nov 14, 2014

Hier in Lübeck haben sich auf unseren 10 Testknoten die häufigen Neustarts nach ein paar Tagen normalisiert und die Knoten halten jetzt wieder Uptimes im Bereich von einigen Tagen bis über 3 Wochen.

Ich werde mal untersuchen, ob die Stabilitätsprobleme vielleicht mit dem neuen Autoupdater zusammenhängen...

@pberndro

This comment has been minimized.

Show comment
Hide comment
@pberndro

pberndro Nov 22, 2014

Contributor

Gibt es schon neue Erkenntnisse im Zusammenhang mit 2014.3.1 und der Stabilität?

Contributor

pberndro commented Nov 22, 2014

Gibt es schon neue Erkenntnisse im Zusammenhang mit 2014.3.1 und der Stabilität?

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Dec 6, 2014

Member

Wir haben leider Grund zur Annahme, dass auch die aktuelle alfred-Version 2014.3, die im Gluon-Master ist, nicht ganz stabil läuft :/

Member

NeoRaider commented Dec 6, 2014

Wir haben leider Grund zur Annahme, dass auch die aktuelle alfred-Version 2014.3, die im Gluon-Master ist, nicht ganz stabil läuft :/

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider
Member

NeoRaider commented Dec 6, 2014

@NeoRaider NeoRaider modified the milestones: 2015.1, 2014.4 Dec 14, 2014

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jan 3, 2015

Member

Ein Log von einem Alfred-Crash unter 2014.4 wäre cool, da unter Barrier Breaker die Kernel-Symbole zur Verfügung stehen.

Nach dem Log von 2014.3.1 würde ich vermuten, dass in alfred alles ok ist, und der Fehler in batman-adv liegt.

Member

NeoRaider commented Jan 3, 2015

Ein Log von einem Alfred-Crash unter 2014.4 wäre cool, da unter Barrier Breaker die Kernel-Symbole zur Verfügung stehen.

Nach dem Log von 2014.3.1 würde ich vermuten, dass in alfred alles ok ist, und der Fehler in batman-adv liegt.

@4ndr3

This comment has been minimized.

Show comment
Hide comment
@4ndr3

4ndr3 Jan 3, 2015

Wir haben 2014.4 als Beta rausgegeben. Wie bekommt man ein Log von dem Crash? dmesg & logread zeigten in der Vergangenheit nichts.

4ndr3 commented Jan 3, 2015

Wir haben 2014.4 als Beta rausgegeben. Wie bekommt man ein Log von dem Crash? dmesg & logread zeigten in der Vergangenheit nichts.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jan 9, 2015

Member

Ich vermute, es war Glück, dass ich da nen Log bekommen habe. Wahrscheinlich gibt es (mindestens) 2 verschiedene Fehler, die Alfred zum Absturz bringen können, und einer davon erzeugt in nen Log in dmesg.

Member

NeoRaider commented Jan 9, 2015

Ich vermute, es war Glück, dass ich da nen Log bekommen habe. Wahrscheinlich gibt es (mindestens) 2 verschiedene Fehler, die Alfred zum Absturz bringen können, und einer davon erzeugt in nen Log in dmesg.

@T-X

This comment has been minimized.

Show comment
Hide comment
@T-X

T-X Jan 9, 2015

Contributor

Alfred-Crash unter 2014.3.1: https://gist.github.com/NeoRaider/607d146fbe0c84fb6aa8

Für mich sieht dieser trace nach einem Crash im Kernel aus. Magst du erläutern, warum du meinst, dass der mit alfred zusammen hängt?

Contributor

T-X commented Jan 9, 2015

Alfred-Crash unter 2014.3.1: https://gist.github.com/NeoRaider/607d146fbe0c84fb6aa8

Für mich sieht dieser trace nach einem Crash im Kernel aus. Magst du erläutern, warum du meinst, dass der mit alfred zusammen hängt?

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Jan 9, 2015

Member

@T-X, siehe Zeile 22: [708035.710000] Process alfred (pid: 1492, threadinfo=80db4000, task=81b16140, tls=77e71440)

Da der Fehler nicht zu nem Reboot geführt hat, sondern alfred danach weg war, ist meine Vermutung, dass das in einem Syscalls von alfred, also im Prozess-Kontext passiert ist. Ich kenne mich leider auch nicht wirklich aus, ob das jetzt eine mögliche Erklärung ist, dass ein Kernel-Oops im Prozess-Kontext zum Tod des Prozesses führen kann, aber das wäre meine Vermutung...

Member

NeoRaider commented Jan 9, 2015

@T-X, siehe Zeile 22: [708035.710000] Process alfred (pid: 1492, threadinfo=80db4000, task=81b16140, tls=77e71440)

Da der Fehler nicht zu nem Reboot geführt hat, sondern alfred danach weg war, ist meine Vermutung, dass das in einem Syscalls von alfred, also im Prozess-Kontext passiert ist. Ich kenne mich leider auch nicht wirklich aus, ob das jetzt eine mögliche Erklärung ist, dass ein Kernel-Oops im Prozess-Kontext zum Tod des Prozesses führen kann, aber das wäre meine Vermutung...

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Apr 25, 2015

Member

Closing; alfred crashes have become very rare. Also, alfred will be replaced by respondd/announced in Gluon 2015.2.

Member

NeoRaider commented Apr 25, 2015

Closing; alfred crashes have become very rare. Also, alfred will be replaced by respondd/announced in Gluon 2015.2.

@NeoRaider NeoRaider closed this Apr 25, 2015

@tcatm tcatm removed the bug label Apr 25, 2015

@ohrensessel

This comment has been minimized.

Show comment
Hide comment
@ohrensessel

ohrensessel Apr 25, 2015

Contributor

I don't know if we really can say that they have become rare. alfred on our gateways crashes quite frequently, if it crashes on nodes we don't know if we cannot distinguish offline nodes. we simply do not know if a node was taken offline by purpose, crashed for some obscur reason, or is seen as offline because alfred crashed.

Contributor

ohrensessel commented Apr 25, 2015

I don't know if we really can say that they have become rare. alfred on our gateways crashes quite frequently, if it crashes on nodes we don't know if we cannot distinguish offline nodes. we simply do not know if a node was taken offline by purpose, crashed for some obscur reason, or is seen as offline because alfred crashed.

@NeoRaider NeoRaider added the bug label May 16, 2015

@NeoRaider NeoRaider reopened this May 16, 2015

@NeoRaider NeoRaider modified the milestones: 2015.2, 2015.1 May 16, 2015

@4ndr3

This comment has been minimized.

Show comment
Hide comment
@4ndr3

4ndr3 Jun 21, 2015

Tritt wieder vermehrt auf Knoten mit 2015.1 auf.

4ndr3 commented Jun 21, 2015

Tritt wieder vermehrt auf Knoten mit 2015.1 auf.

@NeoRaider NeoRaider modified the milestones: next, 2015.2 Aug 29, 2015

@NeoRaider NeoRaider self-assigned this Jan 4, 2016

@NeoRaider NeoRaider modified the milestones: 2016.1, next Jan 4, 2016

@NeoRaider NeoRaider closed this in 0bd0df6 Jan 4, 2016

ecsv pushed a commit to FreifunkVogtland/gluon that referenced this issue Jun 9, 2017

NeoRaider added a commit that referenced this issue Dec 27, 2017

modules: update Gluon packages
57c6796 tunneldigger: clean up version variables in Makefile
90ecf80 tunneldigger: Update to newest upstream commit: (#178)
8769d07 L3roamd bump (#180) -- use all-nodes mac
79583b3 l3roamd: bump version, fix memleaks, adjust output (#177)
030be55 l3roamd: bump version to 2017-12-11
ffd793a libbabelhelper: update version
e0e4fa2 mmfd: bump version (compile fix) (#176)
25123fe bumping versions of l3roamd, mmfd, libbabelhelper
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment