Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Netgear R6220, 19.07 i restarty
Strony Poprzednia 1 2 3 4 … 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
R6220 z allego miał często mocno zajechany nand, jest tu kilka wątków które to opisują. Może nie daje rady czegoś zapisać.odczytać i się restartuje.
samuel.obiedzinski napisał/a:Cezary jak widać nie tylko ja bo Vodnik też. To właściwie on założył ten temat.
Tylko się popiołem bo zauważyłem takie samo zachowanie u siebie.Nie jest też wykluczone, że problem pojawił się w jakimś buildzie.
Ja mam:
root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='19.07.0'
DISTRIB_REVISION='r10860-a3ffeb413b'
DISTRIB_TARGET='ramips/mt7621'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt 19.07.0 r10860-a3ffeb413b'
DISTRIB_TAINTS=''
root@OpenWrt:~# cat /etc/openwrt_version
r10860-a3ffeb413bA to nie mój build
Sprawdź ostatnie, bo to przecież to cały czas poprawiają. A ty siedzisz na pierwszym oficjalnym wydaniu.
Tak nie Twój. Myślałem o wgraniu nowszego, i przeglądałem commity i nic tam nie widać, żeby poprawili coś co mogło by wpłynąć na stabilność pracy na R6220.
Wgram dziś w nocy. Jak rozumiem mogę wgrać z zachowaniem ustawień? Czy lepiej nie?
Zobaczcie co pojawiło się w logach:
[17102.897498] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
[37462.701863] mtk_soc_eth 1e100000.ethernet eth0: port 3 link up
[44229.640871] ------------[ cut here ]------------
[44229.650078] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320 0x8038b320
[44229.664129] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[44229.677981] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE ftdi_sio cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT usbserial slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore
[44229.819049] nls_base usb_common
[44229.825519] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.162 #0
[44229.837635] Stack : 00000000 00000000 00000000 87f21a40 00000000 00000000 00000000 00000000
[44229.854268] 00000000 00000000 00000000 00000000 00000000 00000001 87c0bd60 53261643
[44229.870901] 87c0bdf8 00000000 00000000 00005f00 00000038 8049b778 00000007 00000000
[44229.887533] 00000000 80550000 000c98af 00000000 87c0bd40 00000000 00000000 80509e64
[44229.904163] 8038b320 00000140 00000001 87f21a40 00000000 802ac7c8 00000004 806b0004
[44229.920794] ...
[44229.925653] Call Trace:
[44229.925673] [<8049b778>] 0x8049b778
[44229.937446] [<8038b320>] 0x8038b320
[44229.944377] [<802ac7c8>] 0x802ac7c8
[44229.951311] [<8000c1a0>] 0x8000c1a0
[44229.958242] [<8000c1a8>] 0x8000c1a8
[44229.965170] [<804845e4>] 0x804845e4
[44229.972098] [<80071a00>] 0x80071a00
[44229.979057] [<8002e5f8>] 0x8002e5f8
[44229.985989] [<8038b320>] 0x8038b320
[44229.992921] [<8002e680>] 0x8002e680
[44229.999850] [<80055058>] 0x80055058
[44230.006781] [<8038b320>] 0x8038b320
[44230.013710] [<80099870>] 0x80099870
[44230.020639] [<8038b174>] 0x8038b174
[44230.027567] [<8008843c>] 0x8008843c
[44230.034498] [<800886f8>] 0x800886f8
[44230.041434] [<80079048>] 0x80079048
[44230.048361] [<804a2578>] 0x804a2578
[44230.055308] [<80032f94>] 0x80032f94
[44230.062247] [<80259f50>] 0x80259f50
[44230.069183] [<80007488>] 0x80007488
[44230.076113]
[44230.079239] ---[ end trace 4d6ce3b550e1c600 ]---
[44230.088444] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[44230.100768] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[44230.112753] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=07000000, max=0, ctx=1734, dtx=1734, fdx=1733, next=1734
[44230.134420] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=067a0000, max=0, calc=3841, drx=3842
[44230.156565] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x6060000c, 0x10c = 0x80818
[44230.176236] mtk_soc_eth 1e100000.ethernet: PPE started
[49809.355442] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
[49826.298580] mtk_soc_eth 1e100000.ethernet eth0: port 3 link up
[91264.148430] mtk_soc_eth 1e100000.ethernet eth0: port 3 link down
[119335.610991] mtk_soc_eth 1e100000.ethernet eth0: port 3 link upCo prawda nie spowodowało to restartu routera i sieć ciągle działa.
Znalazłem to issue: https://github.com/openwrt/mt76/issues/211
ostatni post 23 dni temu. Wygląda, że jest jakiś workaround ale nie jest on zintegrowany.
EDIT:
I tu też o tym napisali https://bugs.openwrt.org/index.php?do=d … sk_id=1618
Ja jeszcze nie instalowałem 18.06. W zasadzie go wziąłem bo zmieniłem parametry sieci od UPC z 125 na 300, i moj TPL 4300 nie dawał już rady na Gargoyle, chciałem dac sobie czas na rekonfiguracje i wziąłem R6220. On bez Offload daje radę.
Jak 18.06 nie da rady to zostanę na TPL z Offload. Szkoda tylko zasięgu jaki mam na R6220, bo na nim nie muszę stawiać repeatera w drugim pokoju.
Muszę na zakłądkę zainstalować, aby rodziny nie pozbawiać sieci.
No właśnie wydaje się, że ten błąd który u mnie wyskoczył jest powiązany z wersją kernela i w 18.06 też ten błąd występuje.
Ale to chyba nie jest ten sam błąd który powoduje restart routera no bo po tym błędzie wydaje się, że wszystko działa dalej poprawnie.
z tplinka 4300 spokojnie wyciągniesz z 900Mbit nat z flowoffload,Jeszcze wykręcisz na 680Mhz. Ja zmieniłem go na 6220 tylko z racji wifi ac.
Na n miałem w porywach ze 100Mbit, i to niestabilne.
No właśnie wifi ac mi się spodobało i dlatego chciałbym zostać przy r6220
18.6 z eko jest na pewno stabilny, poszukaj wątków w dziale sprzęt. Można włączyć offload ofc, nawet chyba ten sprzętowy działał poprawnie, był dodany w końcowych wersjach.
Można tez wymusić użycie 2giego wątku cpu.
A jak wymusić drugi wątek w R6220 ? Rozumiem ,że procesor i tak jest jednordzeniowy...
Hej, mam 19.07 zainstalowane na kilku sztukach 6220 z allegro, zacząłem zabawę w czerwcu-lipcu. Przez pierwszych kilka miesięcy były nieustanne restarty, niezależnie od ustawienia offload.
ALE od wydania 10614 z listopada wszystkie sztuki działają bardzo stabilnie. Jeżeli coś się zwiesi to Luci. Wgrywam wydania od Cezarego.
Mam wrażenie że powodem restartów był offload, bo "kiedyś" faktycznie działał -zajętość procesora przy teście była na poziomie 2-3%. Teraz działa chyba tylko sw offload.
masz moze ten obraz pod ręką i mógłbyś go gdiześ wystawić ? Mam Obraz tylko obraz z 25 stycznia, i na nim cuda się dzieją
A jak wymusić drugi wątek w R6220 ? Rozumiem ,że procesor i tak jest jednordzeniowy...
Ja mam 19.07.1 bezpośrednio z openwrt.org i nie mam żadnych nieplanowanych restartów. Zresztą na 19.07.0 też nie miałem. Co do offload to mam włączone jedynie SW. Przy HW zrywa mi połączenie z wewnętrznym serwerem (przekierowanie portów), gdy dostaje się do niego od strony WAN. Chociaż tu podejrzewam, że HW offload z pppoe nie lubią się za nadto :-).
A jaki miałeś maksymalny uptime?
Bo taki samoistny restart to się nie zdarza co parę godzin.
Mój uptime to teraz 3 dni.
Kto wie czy to nie zależy od wersji/rewizji pcb.
Trzeba by bardzo dobrze porównać poszczególne elementy.
Może przy okazji w nowszych wersjach dali jakiś "lepszy" komponent lub z innej serii produkcyjnej.
To co widać na pierwszy rzut oka, to chociażby gniazda na anteny 2,4GHz:
1. lutowane przewody - wersja 1.1 i 1.2:
https://openwrt.org/_media/media/netgea … jpg?cache=
http://image.koolshare.cn/attachment/fo … w0jnzw.jpg
2. gniazda u.fl wersja 1.4:
http://img.expreview.com/review/2015/06 … C_5564.jpg
To był tylko przykład a nie jakiś dowód.
Kto pracuje w firmie produkcyjnej ten wie, że przeważnie schodzi się z kosztów, a tutaj wręcz przeciwnie...
Być może wersje po 200 zł mają ulepszone płyty np. w wersji 1.8 które nie generują problemów...
ja mam same 1.4, ale to nie ma raczej znaczenia. SoC ten sam.
wgrałem właśnie oficjalny 19.07.1 i musze powiedzieć że poprawa względem RC1 jest znaczna.
GUI działa szybko, bez wlaczonego offload mam 500Mbit
z SW offload pełne 600/600, sirq max 71%
HW offload bez zmian - czyli jak dla mnie nie działa, lub offloaduje jakieś sporadyczne połączenia.
po htop widze że ładnie się też rozkłada na 2cpu.
po wifi ac 80 klasyczna bieda - 200Mbit
@samuel.obiedzinski - 62dni na - OpenWrt SNAPSHOT r11159-27bf8abe69
19.07.0 (ok 15 dni, pewnie by dłużej działał, ale wybiło mi korki).
19.07.1 (Zainstalowałem 2 lutego i pewnie by działał do dzisiaj, ale musiałem robić przy prądzie domu).
@chemik89 - jaki masz WAN po ethernet czy pppoe ?
600/50 po ethernecie.
podbiłem jak na razie 3 routery do tej nowej wersji.
główny z zachowaniem ustawień troche warował - nie było w ogóle radia 2.4 dostępnego.
Zgaduj zgadula u mnie dobija 4 dzień mimo tego timeoutu w kolejce (dawałem log z dmesg) zobaczymy ile pociągnie.
Nie wiem może to ma związek z tym, że pod USB mam podpięty konwerter USB <-> serial na chipie FTDI, albo co.
Przez to, że to się nie zdarza tak często to (choć raz się zrestartował po ok 26 h) to ciężko cokolwiek zgadywać.
Miałem też "wyłączone" IPv6 w ten sposób, że w
Global network options > wyczyściłem IPv6 ULA-Prefix
teraz to przywróciłem, żeby mieć jak najbliższa oryginalnej konfiguracje. No i zobaczymy.
Jedyne dodatkowe pakiety jakie mam to driver do FTDI i tyle nawet skrypt do obsługi dynu.com napisałem sobie sam w 50 linijkach, żeby jak najmniej obciążać router. Skrypt co 10 min sprawdza IP zewnętrzne pobierając wgetem stronę http://checkip.dynu.com/ no i porównuje z IP rozwiniętym przez DNS zarejestrowanej domeny, jak różne to wysyła wgetem request do http://api.dynu.com/... żeby zaktualizować IP w bazie.
Mój router naprawdę się nudzi bo ja w maksie jaki ruch generuje to 30Mbitów. Sprawdził bym ten drugi co mam i przygotowałem na 18.06.7 ale sam nie wiem może to "włączenie" ipv6 było powodem niestabilności. Zobaczymy ile wytrzyma teraz.
ja mam same 1.4, ale to nie ma raczej znaczenia. SoC ten sam.
wgrałem właśnie oficjalny 19.07.1 i musze powiedzieć że poprawa względem RC1 jest znaczna.
GUI działa szybko, bez wlaczonego offload mam 500Mbitz SW offload pełne 600/600, sirq max 71%
HW offload bez zmian - czyli jak dla mnie nie działa, lub offloaduje jakieś sporadyczne połączenia.po htop widze że ładnie się też rozkłada na 2cpu.
po wifi ac 80 klasyczna bieda - 200Mbit
1. Chodziło mi raczej o inne elementy pcb takie jak kondensatory, rezystory między rewizjami 1.2 czy 1.4 itp.
Wiem że SoC ten sam
2. Na nowym buildzie od Cezarego bez SW powinieneś zamknąć 600 skoro test iperf3 czy to z Windowsa czy z Linuxa pokazuje odpowiednio 700 i 800 Mbps
Z SW u mnie zamknął łącze Gigabit.
Ale ja nie mam neta Giga więc robie za pomocą iperf3.
3. Wifi zależy od całej masy czynników np. zaszumienie okolicy, karty Wifi, bardziej lub mniej dopracowany sterownik.
W moich warunkach na 2 różnych kartach USB 3.0 mam odpowiednio 200 lub 300 Mbps.
Na Realteku 8812 choćbym nie wiem co robił nie wyskoczę powyżej 220 Mbps
Na Mediateku dobija do 300 prawie zawsze.
W routerze też jest Mediatek i może dlatego lepiej mu się gada z "rodziną"
https://eko.one.pl/forum/viewtopic.php? … 26#p233326
bez SW Cezaremu wyszło 440, ja na RC1 miałem w porywach z 250, więc wynik 499 z 19.07.1 uważam za poprawę.
ipref3 z SW to zamyka gigabit na wszystkim powyżej TPLINKA 1043nd v1 
realnie jednak zwykle mamy więcej niż jedno aktywne połączenie - więc te wyniki są mocno syntetyczne.
do tego ktoś da refresh w luci i już wyniki leca o połowe w dół ;p
tutaj sytacje ratowało HW na starszych wersjach, mimo wysycenia 1gbit cpu było nadal do dyspozycji.
Ja to bym sprawdził/zmienił zasilacz, nie zawsze router jest winien.
bez SW Cezaremu wyszło 440, ja na RC1 miałem w porywach z 250, więc wynik 499 z 19.07.1 uważam za poprawę.
ipref3 z SW to zamyka gigabit na wszystkim powyżej TPLINKA 1043nd v1
realnie jednak zwykle mamy więcej niż jedno aktywne połączenie - więc te wyniki są mocno syntetyczne.
do tego ktoś da refresh w luci i już wyniki leca o połowe w dół ;ptutaj sytacje ratowało HW na starszych wersjach, mimo wysycenia 1gbit cpu było nadal do dyspozycji.
Zgadza się. Masz poprawę ale masz częściowo rację.
1. Cezary robił testy na swoim starszym buildzie stąd 440 bez SW. Ja zrobiłem na nowszym z 08.02 i było o niebo lepiej. Nawet lepiej niż 600 i to bez SW. Dlatego napisałem że powinieneś normalnie wysycić 600 bez dopingu.
2. Nie zawsze iperf3 z SW zamyka Gigabit bo jak zobaczysz przytoczone przez Ciebie testy Cezarego to widnieje tam cyfra 830 Mbps z SW.
Czyli ktoś, kto widział tylko ten test, mógłby rzec, że nie zawsze pęknie Gigabit na wszystkim powyżej 1043v1.
Taki chichot losu
3. Luci nie jest potrzebne do działania routera.
Nie rozumiem dlaczego ludzie obarczają router zbędnymi śmieciami.
To tak jakby zaciągnąć ręczny hamulec i sprawdzać osiagi auta
Na Marvellowych starych ARMach też gigabit z offloadingiem nie pęka. A zegar 1.2 GHz...
nie ma chyba oficjalnych obrazów bez luci w gałęzi stabilnej openwrt.
Od eko to jednak zawsze trzeba troche poczekać na build a samemu sie nie chce.
No i Luci przytoczyłem jako przykład - może być to dowolna inna usługa działająca w tle.
a to że nie pęka gigabit na niektórych urządzeniach to raczej kwestia zastosowanego kontrolera ethernet niż samego cpu.
Mam płytę na B450 z ryzenem - na kontrolerze Realteca 8111H i też nie wyciąga nawet 900Mbit
Strony Poprzednia 1 2 3 4 … 8 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Netgear R6220, 19.07 i restarty
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc
