Turris 1.x eth2 driver problem

Ahoj všichni,

je to již nějaký čas co jsem s podporou řešil problém padajícího připojení, ovšem jsem nenalezl uspokojivý výsledek.

Vlastním 3x Turris 1.x a pokud se vyjedná připojení na rozhraní WAN (eth2) v rychlosti 100 mbps tak po určitém čase spadne.

Problém se projevuje od TOS4 a výše.
Dle hledání by měl být problém v ovladači.

Při připojení přes pppoe vypadá dmesg následovně:

fsl-gianfar ffe26000.ethernet eth2: Link is Down
fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off

při statické adrese:

[ 341.998667] fsl-gianfar ffe26000.ethernet eth2: Link is Down
[ 343.024858] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off
[ 519.639793] conntrack: generic helper won't handle protocol 47. Please consider loading the specific helper module.
[ 3506.448096] NETDEV WATCHDOG: eth2 (fsl-gianfar): transmit queue 0 timed out
[ 3506.455263] ------------[ cut here ]------------
[ 3506.459893] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x188/0x2d0
[ 3506.468147] Modules linked in: sch_cake ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_NFQUEUE xt_NFLOG xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda slhc rtc_ds1307 nfnetlink_queue nfnetlink_log nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_ftp nf_nat
[ 3506.538909] nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack_ftp nf_conntrack lm90 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables hwmon ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt compat br_netfilter sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred configs xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink
[ 3506.609818] nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb sit ip6_tunnel tunnel6 tunnel4 ip_tunnel gpio_keys leds_gpio xhci_plat_hcd xhci_pci xhci_hcd ehci_platform button_hotplug
[ 3506.631410] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.248 #0
[ 3506.637496] task: ee84c880 task.stack: ee86a000
[ 3506.642019] NIP: c05ae9fc LR: c05ae9fc CTR: c04470cc
[ 3506.647063] REGS: ee86bcc0 TRAP: 0700 Not tainted (4.14.248)
[ 3506.652973] MSR: 00029000 <CE,EE,ME> CR: 24000222 XER: 00000000
[ 3506.659156]
[ 3506.659156] GPR00: c05ae9fc ee86bd70 ee84c880 0000003f eedcf368 eedd3fac 2e555000 ee86a000
[ 3506.659156] GPR08: 00000007 00000000 00000000 00000007 24000282 00000000 00200042 00000000
[ 3506.659156] GPR16: c06de378 c07c61a0 c08b0000 000c3c01 2e555000 c08b1ca4 c087e3a0 00000001
[ 3506.659156] GPR24: 00000001 ffffffff 00000000 00000004 000000c0 c08b0000 eeb42000 00000000
[ 3506.694065] NIP [c05ae9fc] dev_watchdog+0x188/0x2d0
[ 3506.698937] LR [c05ae9fc] dev_watchdog+0x188/0x2d0
[ 3506.703718] Call Trace:
[ 3506.706160] [ee86bd70] [c05ae9fc] dev_watchdog+0x188/0x2d0 (unreliable)
[ 3506.712777] [ee86bda0] [c00925dc] call_timer_fn.isra.25+0x30/0x94
[ 3506.718866] [ee86bdc0] [c00927e8] run_timer_softirq+0x1a8/0x230
[ 3506.724788] [ee86be30] [c06dab0c] __do_softirq+0x134/0x258
[ 3506.730270] [ee86be80] [c0039228] irq_exit+0x90/0xac
[ 3506.735240] [ee86be90] [c000ab28] timer_interrupt+0xb0/0xe0
[ 3506.740814] [ee86beb0] [c0011944] ret_from_except+0x0/0x18
[ 3506.746299] --- interrupt: 901 at arch_cpu_idle+0x24/0x60
[ 3506.746299] LR = arch_cpu_idle+0x24/0x60
[ 3506.755946] [ee86bf70] [00000002] 0x2 (unreliable)
[ 3506.760746] [ee86bf80] [c00746b0] do_idle+0xc4/0x144
[ 3506.765707] [ee86bfa0] [c0074874] cpu_startup_entry+0x24/0x28
[ 3506.771452] [ee86bfb0] [c0012d68] start_secondary+0x360/0x364
[ 3506.777194] [ee86bff0] [c00021b8] __secondary_start+0x7c/0xc8
[ 3506.782932] Instruction dump:
[ 3506.785893] 4200ffb8 48000048 39200001 7fc3f378 9928b4ab 4bfda2f5 3d20c081 7c651b78
[ 3506.793645] 7fe6fb78 3869fe90 7fc4f378 4bad07b9 <0fe00000> 813e0128 7fc3f378 8129003c
[ 3506.801572] ---[ end trace 883942b6cf787185 ]---
[ 3506.868365] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control off

Řešení je použít namapování jiného portu na rozhraní WAN, ovšem tam se potýkám s propady rychlosti připojení.

Nenapadá náhodou někoho nějaké jiné řešení?

Problém se dá reprodukovat při použití 100mbitu

ethtool -s eth2 speed 100 autoneg off
časem linka spadne.

Díky za případné náměty
czl

Tak dle hledání byl již podobný/stejný problém popsán.

Myslíte že by se někdo na to mohl podívat u Vás v labu @Pepe @miska @vojtech.myslivec ?

https://www.spinics.net/lists/netdev/msg683425.html
https://openwrt-devel.openwrt.narkive.com/M8xo2hAp/problems-with-link-down-up-on-boards-with-fsl-p1010-p1020-gianfar-driver-at-100-mbit-s

//Přemluvil jsem isp na přepojení portu na gbit, ovšem chyba se projevovala stále.

V TOS6 se problém opět neprojevuje, takže vyřešeno.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.

Follow-up: WAN (eth2) issue on turris v1 with 5.3.3

TL;DR: WAN (eth2) issue on turris v1 with 5.x (#323) · Issues · Turris / Turris OS / Turris Build · GitLab

Jelikož tohle jsem hlásil již v beta verzi TOS 4.0 a bylo řešeno (z mé strany) s výsledkem “přemapování” na lan1 bez dalšího povšimnutí je toto řešení bezpředmětné. Opět hlášeno a ticho po pěšině. Vyřešeno přesunutím do TOS6 v hdb. Jen trvala ta úprava kernelu pro boot v TOS6.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.