phy0 DMA failed - CPE210

Kleine Zwischenmeldung: Auch aktuell, mit neuem Gluon, hat das Problem noch Bestand.

was meinst du mit „neuem“ gluon … master ? oder tag v2016.2.2?

1 „Gefällt mir“

Ok ok, das war schwammig – zugegeben.

Ich meinte Tag/Release 2016.2.1 (von 2016.2.2 wusste ich bis gerade noch gar nichts.) :slight_smile:

Wobei ja nach wie vor die These im Raum steht, dass die Syslogmeldung „phy0 DMA failed“ noch nicht per se ein Fehlerzustand ist, der irgendwie „schlimm“ ist.
Zumindest gibt es nodes, die das Log damit fluten und der Beschreibung nach aber einwandfrei zu funktionieren scheinen was Wifi (AP und Mesh) anbelangt.
Wobei es natürlich nicht heisst, dass nicht vielleicht das doch dann „Packet Loss“ ist, und ohne das die Leistung/die Links besser wären.

Tja, was ist eigentlich, wenn „phy0 DMA failed“ nur eine harmlose Fehlermeldung ist und das Problem, welches wir wirklich haben, gar keine Fehlermeldung erzeugt, weils nicht richtig abgefangen ist?

1 „Gefällt mir“

Es gibt ja dazu mehrere Tickets im openwrt/lede Umfeld, quasi seit Monaten. Wir haben das Problem auch mit unserer Freifunk Meshkit Firmware, basierend auf Lede trunk.
Als Zwischenmitteilung erwähnenswert ist, dass der Fehler vielleicht gefunden und behoben wurde. Ich habe es mittlerweile auch schon in den logs gesehen, dass die Fehlermeldung kam, aber das WLAN NICHT mehr abbrach :smile:

ich hab hier gerade zum 2. mal in kurzer Zeit (10 Stunden uptime)

[37851.420000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02100020 DMADBG_7=0x00024300

Effekt aber nicht Wifi , sondern br-wan und eth0.1 down … und das fastd will ohne einen eigenen restart auch die reparatur nicht futtern

funktionierendes Netz

nach folgenden befehlen ging daskomplette netz , also nslookup, ping , dhcp …

br-wan down
eth0.1 down
ifconfig br-wan up
ifconfig eth0.1 up
brctl addif br-wan eth0.1
udhcpc -i br-wan -b -n

fastd

allerdings war der fastd daemon nicht in der lage die ns domain aufzulösen (meine vermutung)

/etc/init.d/fastd restart 
# logread
...
Tue Feb 21 02:19:53 2017 daemon.info fastd[20302]: resolving host `sn7.freiburg.freifunk.net' failed: Name or service not known
Tue Feb 21 02:19:53 2017 daemon.info fastd[20302]: resolving host `sn15.freiburg.freifunk.net' failed: Name or service not known
Tue Feb 21 02:19:53 2017 daemon.info fastd[20302]: resolving host `sn2.freiburg.freifunk.net' failed: Name or service not known
Tue Feb 21 02:19:53 2017 kern.info kernel: [50473.250000] batman_adv: bat0: Adding interface: mesh-vpn
Tue Feb 21 02:19:53 2017 kern.info kernel: [50473.250000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1280) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1528 would solve the problem.
Tue Feb 21 02:19:53 2017 kern.info kernel: [50473.280000] batman_adv: bat0: Interface activated: mesh-vpn
Tue Feb 21 02:19:53 2017 kern.info kernel: [50473.290000] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Tue Feb 21 02:19:53 2017 daemon.notice netifd: Interface 'mesh_vpn' is now up
Tue Feb 21 02:19:55 2017 daemon.info fastd[20302]: sending handshake to <mesh_vpn_backbone_peer_sn16>[176.9.68.44:10016]...
Tue Feb 21 02:19:55 2017 daemon.info fastd[20302]: received handshake response from <mesh_vpn_backbone_peer_sn16>[176.9.68.44:10016] using fastd v17
Tue Feb 21 02:19:56 2017 daemon.info fastd[20302]: 176.9.68.44:10016 authorized as <mesh_vpn_backbone_peer_sn16>
Tue Feb 21 02:19:56 2017 daemon.notice fastd[20302]: connection with <mesh_vpn_backbone_peer_sn16> established.

firmware

ibss0 adhoc Netze , an cpe210 - gluon 2016.2.3 tag , fastd uplink

Auf WAN macht bei mir ein 841v10 das rund einmal die Woche: Wanmesh (MoW) ist dann „tot“… aber das Check-Script rettet den Knoten dann 3 mal „Keine Neighbors mehr auf dem Interface“.

betonung liegt hier auf ein ? also einer neben vielen potentiell anderen?

Exakt einer, ja, ich gehe von einem Hardware-Fehler aus.
Nur fakt ist, dass ich mehrere habe mit solchen Effekten. Klar, die sind irgendwie semi-defekt.
Und bei einem normalen Kunden würde das nie auffallen. Der würde powercyclen und auf den Hersteller fluchen.
Wir haben jedoch eine so große installed base, dass wir solche Dinge sehen, wenn wir unsere Netze monitoren.

Ich könnte so eine Kiste auf wegwerfen. In besagtem Fall sicher schon. Ich hatte soetwas aber auch schon auf einem Node, der auf einer Fensterbank an einem Standort ohne mittelfristigen Zugang hängt. Und da war ich froh, mich mit einem cronjob retten zu können.

1 „Gefällt mir“

ich habe das problem konkret hier auch wenn nichts mit dma und so im dmesg log steht,
stehts mindestens (sonst muss man das auch noch wieder hoch holen) eth0.1 nicht mehr in der bridge und entsprechend folgende schritte nötig:

brctl addif br-wan eth0.1
udhcpc -i br-wan -b -n
/etc/init.d/fastd restart

@adorfer, hast du dazu noch ein offenes issue, oder kennst du eines ?

Nein, habe kein offenes Issue.
Erstmal warte ich darauf, dass die Dinger sauber mit „MoW+MoL“ booten, wenn kein phy Link hat.

die zwei hier angesprochenen Probleme haben zwar nichts miteinander zu tun, aber trotzdem:

  • wifi… „wlan fällt bis zum nächsten WLAN-Scan aus“-bug:
    das ist doch ein allgemeines openwrt-cc Problem, scheinbar auch im lede-17.01 nicht gänzlich gelöst… Den Zusammenhang mit der CPE210 (siehe Betreff) verstehe ich noch nicht, betrifft es doch viele Geräte…

  • wan-bridge fällt auseinander:
    Sowas ist mir auch mit batman-adv Interfaces in älteren Openwrt Versionen schon öfters passiert. Welche FIrmware wird denn verwendet, weißt du Details?

1 „Gefällt mir“

oh, Versionsnummern sind ja schon im Thread erwähnt…