Alfred: page allocation failure

Hallo @ all

Ein von mir betriebener TP841 v9.2 Firmware 0.6 im FF Ruhrgebiet wird regelmäßig in der Map als offline angezeigt. Der Router wird einzeln in einem Haushalt direkt an dem Router des ISP betrieben.

Hier mal ein Ausschnitt aus dem Log:
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.480000] alfred: page allocation failure: order:6, mode:0x1040d0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.480000] CPU: 0 PID: 1400 Comm: alfred Not tainted 3.10.49 #1
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] Stack : 00000000 00000000 00000000 00000000 803bce76 00000034 81725ac8 00000000
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] 802f5bc8 8033f9a3 00000578 803b3a00 81725ac8 00000000 00000001 00000000
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] 00000001 80290d60 00000000 801f39cc 00000006 81613d44 802f7258 81613d64
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81613cf0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.490000] …
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.530000] Call Trace:
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.530000] [<80235a54>] show_stack+0x48/0x70
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.530000] [<802a066c>] warn_alloc_failed+0x108/0x12c
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.540000] [<80081e48>] __alloc_pages_nodemask+0x3a0/0x634
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.550000] [<800930f8>] __get_free_pages+0x18/0x4c
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.550000] [<802242d0>] seq_read+0x270/0x48c
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.560000] [<80296ac4>] vfs_read+0xa4/0x164
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.560000] [<80078198>] SyS_read+0x58/0xa4
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.560000] [<800625b0>] stack_done+0x20/0x44
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.570000]
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.570000] Mem-Info:
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.570000] Normal per-cpu:
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] CPU 0: hi: 0, btch: 1 usd: 0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] active_anon:1044 inactive_anon:15 isolated_anon:0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] active_file:28 inactive_file:31 isolated_file:0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] unevictable:0 dirty:0 writeback:0 unstable:0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] free:1411 slab_reclaimable:299 slab_unreclaimable:2048
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] mapped:1 shmem:39 pagetables:119 bounce:0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.580000] free_cma:0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.610000] Normal free:5644kB min:676kB low:844kB high:1012kB active_anon:4176kB inactive_anon:60kB active_file:112kB inactive_file:124kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32768kB managed:28592kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:156kB slab_reclaimable:1196kB slab_unreclaimable:8192kB kernel_stack:416kB pagetables:476kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:140 all_unreclaimable? no
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.660000] lowmem_reserve[]: 0 0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.660000] Normal: 3994kB (UMR) 2388kB (EMR) 7316kB (MR) 1332kB (R) 264kB (R) 1128kB (R) 1256kB (R) 0512kB 01024kB 02048kB 0*4096kB = 5596kB
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.670000] 98 total pagecache pages
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.680000] 0 pages in swap cache
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.680000] Swap cache stats: add 0, delete 0, find 0/0
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.690000] Free swap = 0kB
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.690000] Total swap = 0kB
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.690000] 8192 pages RAM
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.700000] 977 pages reserved
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.700000] 263143 pages shared
Wed Apr 8 11:03:34 2015 kern.warn kernel: [36605.700000] 5245 pages non-shared

Dieser Fehler kommt fast sekündlich bis er nach etlichen Minuten wieder online ist und er wieder für einen längeren Zeitraum online dargestellt wird. Das Routing schein aber noch ganz normal zu laufen, ein Ping auf google über ssh - der Router steht nicht bei mir zuhause - zeigt keine Auffälligkeiten.

Gruß

Saho

Versuche den Freifunk-Router mal testweise in ein Netz zu hängen, in denen es KEIN IPv6 gibt.

Danke für die Antwort!

Wie kann ich dies beeinflussen? Der Router verbindet sich doch automatisch mit einem Supernote der gerade am besten erscheint.

Ich kann mir gut vorstellen, dass es an dem ISP liegt. Ich hatte den Router zuvor bei mir zuhause eingerichtet (Unitymedia) und da lief er einwandfrei, jetzt hängt er hinter einem TOnline-Anschluß.

Gruß

Saho

Beeinflussen kannst du es nur, in dem Du ggf. an der Configuration Deines Homerouters etwas tust.

Wie beobachten, dass einige Routermodelle mit 32MB RAM obiges Verhalten zeigen, wenn sie WAN-seitig an Netzen mit IPv6 hängen (selbst wenn der Provider „nur“ IPv4 macht). Es geht wohl eher um RouteAnnouncements auf dem IPv6, was auch diverse Terredo- und andere Tunnel-provider-Lösungen hinbekommen.

Leider habe ich keinen Zugriff auf den Router des ISP da ich den FF-Router nur mit Erlaubnis des Anschlußnehmers für seine Ferienwohnung aufstellen sollte und er mit Analysemaßnahmen bestimmt überfordert wäre.

Da aber der eigentliche Zweck, Internet für die Gäste anzubieten, funktioniert werde ich wohl damit leben müssen.

Danke für deine Antwort

Vielleicht mag @tweibert etwas sagen, ob es etwas gebracht hat, IPv6 in der AdvancedConfig zu deaktivieren. Oder ob es auch passierte, wenn v6 nicht genutzt wurde vom Fastd.

Ich habe das Problem mit meiner Picostation. Habe sie jetzt einige Tage laufen lassen (und ein Script auf einem meiner Rootserver, das 1x pro Minute die von alfred gemeldete Uptime protokolliert).

Fazit: Ich habe absolut keine Anhaltspunkte, woran es liegen kann. Manchmal hält sie 1 Minute durch, manchmal einen ganzen Tag. Egal ob IPv6 WAN-seitig an oder aus, andere Router in der Nähe oder nicht, VPN an oder aus, WAN eingestöpselt oder nicht, Sonne scheint oder Regen… Die Abstürze sind absolut zufällig.

Meine Vermutung geht dahin, dass es irgendwie an der „Netzauslastung“ in der Ruhrgebiet-Domäne liegt. Viele IPv6-Announcements oder was weiß ich. So richtig debuggen kann ich das nicht.

Wir sollen hier in Dortmund ja bald eine eigene Domäne kriegen, vielleicht löst sich das Problem bei mir dann von selbst.

@tweibert Danke für die Info.
Ich hoffe schlicht auch darauf, dass mit Verkleinerung der Kollisionsdomain auf „weniger als 300 Nodes“ viele Probleme einfach von selbst verschwinden werden.