Hi,
der Bug zum TL-wr841n-nd-v5 ist doch wohl nicht behoben…
Upstream tickets:
https://dev.openwrt.org/ticket/21773 https://dev.openwrt.org/ticket/21857
Wie geht ihr damit in eurer Firmware Entwicklung um?
fuzzle
March 22, 2016, 3:46pm
#2
bauchschmerzen …
opened 02:46PM - 21 Mar 16 UTC
closed 09:55PM - 24 Mar 16 UTC
2. status: duplicate
so, i am hunting the reasons now .. (and edit this : when i get more info in the… se days)
while nodes get there autoupdate normaly, some of them did not come back. The Nodes are 841v9 and 841v10 .. there are updating from a 2-3 week old master to a 5 day old master ...
Source is generaly here: https://cccfr.de/git/viisauksena/firmware/tree/support/
one Node at my home give the hint : it was without reason in config mode - this could be by accident, i will go to the places where the other nodes are installed and try to find out more ..
maybe its related to this, also not so precise bug description: https://github.com/freifunk-gluon/gluon/issues/635
http://oi66.tinypic.com/4pxxrq.jpg
http://oi68.tinypic.com/5xu6tk.jpg
http://oi64.tinypic.com/29kthqa.jpg
opened 07:03PM - 29 Feb 16 UTC
closed 05:41PM - 31 Mar 16 UTC
0. type: bug
9. meta: upstream issue
We've observed that on rare occasions, Gluon would produce images that would alm… ost always fail to boot.
Our analysis has yieded the following results so far:
- The kernel will always hang after the message "console [ttyS0] disabled"
- The production of broken images is nondeterministic, the same source code may produce working and broken images when compiled multiple times
- The only differences between working and broken kernels are timestamps in the uname line and the initcpio (uncompressed; after LZMA compression, the kernel images would be mostly different)
- We suspect an issue in the LZMA loader, as the kernel image itself seems to be fine when uncompressed on the build machine
- We are currently verifying if a backport of http://git.openwrt.org/?p=openwrt.git;a=commit;h=4765fe077fef2b281ef8f4607be75793e8372f59 fixes the issue
hast du einen generellen Verdacht … dann probier ich das mal mit der Freiburger FW … sonst natürlich nicht.
in Freiburg ist vermutlich davon betroffen gewesen 1 cpe 210v1 , mehrere 841v9 und 841v10 - etwa bei etwa 150 autoupdates haben wir 8 etwa 10 ausfälle, wobei davon auch 2-4 fehlgeschlagene sysupgrades (darunter keine cpe) sind (reboot im upgrade prozess)
Ja, Bauchschmerzen habe ich auch. Ohnehin haben wir grade in unserem Netz über 1000 aktive Router, davon knapp 450 Stück 841er v8 und v9 :-/
Habt ihr denn schon definitive Fälle gehabt wo dieses Problem bestand?
MPW
March 22, 2016, 11:17pm
#4
Mir dämmert gerade, dass dieses Problem die Ursache für die Geräte gewesen sein könnte, die gar nichts mehr getan haben und wo nur noch die Power-LED leuchtete. Per TFTP konnten die aber wiederbelebt werden.
Frage: Könnte das Problem auch schon von 2015.1.2 nach 2016.1 aufgetreten sein? Oder von wo nach wo war das neu?
fuzzle
March 24, 2016, 3:52pm
#5
spätesetens ab chaos calmer openwrt,
1 Like
committed 05:34PM - 24 Mar 16 UTC
Original commit message:
MIPS: ath79: make bootconsole wait for both THRE a… nd TEMT
This makes the ath79 bootconsole behave the same way as the generic 8250
bootconsole.
Also waiting for TEMT (transmit buffer is empty) instead of just THRE
(transmit buffer is not full) ensures that all characters have been
transmitted before the real serial driver starts reconfiguring the serial
controller (which would sometimes result in garbage being transmitted.)
This change does not cause a visible performance loss.
In addition, this seems to fix a hang observed in certain configurations on
many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver.
A more complete follow-up patch will disable 8250 autoconfig for ath79
altogether (the serial controller is detected as a 16550A, which is not
fully compatible with the ath79 serial, and the autoconfig may lead to
undefined behavior on ath79.)
Gluon 2016.1.3 incoming…
Manchmal frag ich mich echt, was wir ohne den Neoraider alle machen würden
2 Likes
MPW
March 25, 2016, 11:51am
#7
Okay, also könnte man quasi jetzt schon v2016.1.x nutzen, wenn man autoupdates fahren muss.
Es betrifft aber doch such Nanostations und nicht nur TP-Link 841er, oder?
