Dotaz: zatuhnutí síťovky

[Milan Uhrák]

Zdravím všechny..

Při používání zálohovacího serveru mně pronásleduje tuhnutí síťových karet.

ze svého PC (nebo ze serveru) připojuji zálohovací disk pomocí sshfs. v zálohovacím PC je integrovaná VIA 100M a PCI realtek 1G. propojeno 1G routerem.

Data se přenáší odpovídající rychlostí (podle toho, jakou síťovku připojím) a po čase delta náhoda síťovka vytuhne. (přeneseno nejméně (prozatím) 3.8GB, nejvíce 21GB). Restart routeru nepomůže, restart zálohovacího PC ano.

když kouknu na konzoli vytuhlého, normálka funguje, ping na sebe sama (na tu vytuhlou síťovku) jede jako víno, jinam se nepingnu. Ifdown trvá asi 15sek, ifconfig pak ukáže kartu vypnutou. Ifup poté kartu nahodí okamžitě, ale ta stále nekomunikuje (nedostane ani IP od DHCP)

jedinou stopu po pachateli jsem našel ve /var/log/warn (pokud mám hledat ještě někde jinde, pak prosím o radu, kde). přikládám inkriminovanou pasáž.

OS je opensuse 13.1 64

2014-02-05T09:02:40.456476+01:00 backuper kernel: [ 4312.708020] ------------[ cut here ]------------
2014-02-05T09:02:40.456521+01:00 backuper kernel: [ 4312.708061] WARNING: CPU: 0 PID: 0 at /home/abuild/rpmbuild/BUILD/kernel-desktop-3.11.6/linux-3.11/net/sched/sch_generic.c:260 dev_watchdog+0x240/0x250()
2014-02-05T09:02:40.456530+01:00 backuper kernel: [ 4312.708073] Modules linked in: af_packet snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq snd_timer powernow_k8 kvm_amd snd_seq_device sr_mod cdrom edac_core serio_raw kvm via_rhine r8169 pcspkr edac_mce_amd mii k8temp snd soundcore snd_page_alloc i2c_viapro pata_via ata_generic shpchp mperf button sg dm_mod autofs4 sata_via processor thermal_sys scsi_dh_alua scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh
2014-02-05T09:02:40.456535+01:00 backuper kernel: [ 4312.708138] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.6-4-desktop #1
2014-02-05T09:02:40.456538+01:00 backuper kernel: [ 4312.708144] Hardware name: MICRO-STAR INTERNATIONAL CO., LTD MS-7253/MS-7253, BIOS V1.4 06/27/2007
2014-02-05T09:02:40.456541+01:00 backuper kernel: [ 4312.708149]  0000000000000009 ffffffff815a9bd7 ffff88003bc03dd8 ffffffff81050eb2
2014-02-05T09:02:40.456544+01:00 backuper kernel: [ 4312.708158]  0000000000000000 ffff88003bc03e28 0000000000000001 ffff8800376a8320
2014-02-05T09:02:40.456547+01:00 backuper kernel: [ 4312.708166]  0000000000000000 ffffffff81050f17 ffffffff81867610 ffff880000000030
2014-02-05T09:02:40.456551+01:00 backuper kernel: [ 4312.708174] Call Trace:
2014-02-05T09:02:40.456554+01:00 backuper kernel: [ 4312.708205]  [<ffffffff81004a18>] dump_trace+0x88/0x310
2014-02-05T09:02:40.456557+01:00 backuper kernel: [ 4312.708218]  [<ffffffff81004d70>] show_stack_log_lvl+0xd0/0x1d0
2014-02-05T09:02:40.456560+01:00 backuper kernel: [ 4312.708229]  [<ffffffff810061bc>] show_stack+0x1c/0x50
2014-02-05T09:02:40.456563+01:00 backuper kernel: [ 4312.708244]  [<ffffffff815a9bd7>] dump_stack+0x50/0x89
2014-02-05T09:02:40.456566+01:00 backuper kernel: [ 4312.708259]  [<ffffffff81050eb2>] warn_slowpath_common+0x72/0x90
2014-02-05T09:02:40.456570+01:00 backuper kernel: [ 4312.708271]  [<ffffffff81050f17>] warn_slowpath_fmt+0x47/0x50
2014-02-05T09:02:40.456572+01:00 backuper kernel: [ 4312.708281]  [<ffffffff814e52c0>] dev_watchdog+0x240/0x250
2014-02-05T09:02:40.456575+01:00 backuper kernel: [ 4312.708298]  [<ffffffff8105dadc>] call_timer_fn+0x2c/0x190
2014-02-05T09:02:40.456578+01:00 backuper kernel: [ 4312.708311]  [<ffffffff8105de53>] run_timer_softirq+0x213/0x2d0
2014-02-05T09:02:40.456581+01:00 backuper kernel: [ 4312.708323]  [<ffffffff810563c4>] __do_softirq+0xf4/0x2b0
2014-02-05T09:02:40.456584+01:00 backuper kernel: [ 4312.708340]  [<ffffffff815b92dc>] call_softirq+0x1c/0x30
2014-02-05T09:02:40.456587+01:00 backuper kernel: [ 4312.708350]  [<ffffffff81004955>] do_softirq+0x55/0x90
2014-02-05T09:02:40.456590+01:00 backuper kernel: [ 4312.708360]  [<ffffffff810566d5>] irq_exit+0x95/0xa0
2014-02-05T09:02:40.456595+01:00 backuper kernel: [ 4312.708375]  [<ffffffff8102f81b>] smp_apic_timer_interrupt+0x3b/0x50
2014-02-05T09:02:40.456598+01:00 backuper kernel: [ 4312.708386]  [<ffffffff815b861d>] apic_timer_interrupt+0x6d/0x80
2014-02-05T09:02:40.456601+01:00 backuper kernel: [ 4312.708404]  [<ffffffff8103b032>] native_safe_halt+0x2/0x10
2014-02-05T09:02:40.456603+01:00 backuper kernel: [ 4312.708417]  [<ffffffff8100b0e4>] default_idle+0x14/0x130
2014-02-05T09:02:40.456606+01:00 backuper kernel: [ 4312.708428]  [<ffffffff8100b237>] amd_e400_idle+0x37/0xf0
2014-02-05T09:02:40.456609+01:00 backuper kernel: [ 4312.708440]  [<ffffffff810a16c8>] cpu_startup_entry+0xc8/0x2e0
2014-02-05T09:02:40.456612+01:00 backuper kernel: [ 4312.708457]  [<ffffffff81cd9eb5>] start_kernel+0x443/0x44e
2014-02-05T09:02:40.456615+01:00 backuper kernel: [ 4312.708469]  [<ffffffff81cd96b0>] x86_64_start_kernel+0x10c/0x11b
2014-02-05T09:02:40.456618+01:00 backuper kernel: [ 4312.708478] ---[ end trace ec9757c1700ce6d3 ]---
2014-02-05T09:02:40.456621+01:00 backuper kernel: [ 4312.708644] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:03:14.455953+01:00 backuper kernel: [ 4346.708180] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
2014-02-05T09:04:58.455949+01:00 backuper kernel: [ 4450.708179] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:06:12.455949+01:00 backuper kernel: [ 4524.708178] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:07:04.455948+01:00 backuper kernel: [ 4576.708180] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
2014-02-05T09:08:36.455946+01:00 backuper kernel: [ 4668.708181] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:09:46.455946+01:00 backuper kernel: [ 4738.708180] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:11:22.455944+01:00 backuper kernel: [ 4834.708179] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 5003, PHY status 786d, resetting...
2014-02-05T09:12:42.456752+01:00 backuper kernel: [ 4914.708182] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:13:38.455952+01:00 backuper kernel: [ 4970.708179] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:14:52.455957+01:00 backuper kernel: [ 5044.708182] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:15:54.455954+01:00 backuper kernel: [ 5106.708180] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:17:00.455975+01:00 backuper kernel: [ 5172.708203] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:17:52.455954+01:00 backuper kernel: [ 5224.708181] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:18:46.455972+01:00 backuper kernel: [ 5278.708201] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 5003, PHY status 786d, resetting...
2014-02-05T09:19:24.455954+01:00 backuper kernel: [ 5316.708182] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 0003, PHY status 786d, resetting...
2014-02-05T09:20:20.455952+01:00 backuper kernel: [ 5372.708182] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 1003, PHY status 786d, resetting...
2014-02-05T09:21:03.269837+01:00 backuper ifplugd(eth0)[1133]: Killing child.
2014-02-05T09:21:03.270298+01:00 backuper ifplugd(eth0)[1133]: Program execution failed, return value is 0.
2014-02-05T09:21:18.008234+01:00 backuper ifplugd(eth0)[3804]: client:     eth0      device: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)
2014-02-05T09:21:37.493843+01:00 backuper ifplugd(eth0)[3804]: client: Starting DHCP4 client on eth0. . . . . . . .
2014-02-05T09:21:37.502990+01:00 backuper ifplugd(eth0)[3804]: client:     eth0      DHCP4 continues in background
2014-02-05T09:21:37.617105+01:00 backuper ifplugd(eth0)[3804]: Program execution failed, return value is 12.
2014-02-05T09:21:38.696114+01:00 backuper dhcpcd[4004]: eth0: timed out
2014-02-05T09:21:46.455957+01:00 backuper kernel: [ 5458.708181] via-rhine 0000:00:12.0 eth0: Transmit timed out, status 0003, PHY status 786d, resetting...

Má někdo z vás odborníků tucha, co se tam vlastně děje ? kde je problém? (od včera jsem tam pustil memtest, dnes ráno byla obrazovka čistá, bez chyb)

Mně jedině napadá, že chipset tý levný desky je prostě šunt.

Včera jsem ještě pátral u Strejdy Brejly, ale jaksi s mou angličtinou nedokážu sestavit dotaz, který by mně vůbec někam navedl. " hang NIC " mě většinou dostalo na M$ fóra, problémy podobné, řešení stejně většinou nenalezeno. a bylo by asi pro mne nepoužitelné, i kdyby problém u NICH řešení měl.

Předem díky za nějakou tu radu (kup novou desku prozatím neberu - snad se to pořeší jinak)

Milan

---

---

Odpovědi

[NN]

http://www.abclinuxu.cz/poradna/linux/show/387559

[Milan Uhrák]

NN, děkuji za odpověď ... jinak .. všímám si, že vaše odpovědi jsou vždy stručné a přesné, máte mé uznání.

Z vašeho odkazu a diskuse v odkazovaném odkazu .. ehm .. odkazu jsem toho ale příliš nepobral. na konci je odkaz na duplicitní bug, a jediné, co jsem z toho duplicitního hlášení bugu byl schopen pojmout, je, že chyba popisovaná v bugu https://bugzilla.redhat.com/show_bug.cgi?id=681017 nenastane pokud jádro dostane parametr pci=noaer. Nicméně popisovaný problém se týkal 2.6 (s tím, že v novějším 2.6.xx - jak jsem pochopil- tento problém odstraňuje), na PC ale mám 3.11..

Tak nevím, zkusím ten parametr jádra, víc jsem z toho odkazu nevyždímal.

i tak díky

Milan

[Michal Kubeček]

S tou duplicitou bych byl opatrný. Netdev watchdog timeout znamená jen tolik, že jádro předalo síťové kartě data k odeslání, ale do nějakého limitu (typicky sekundy, u Intelu IIRC pět) nedostalo potvrzení, že data opravdu odešla. Což může znamenat v podstatě cokoli od chyby v driveru přes chybu firmware až po chybu hardware. Bez podrobnějších debugovacích informací a hlubší znalosti driveru těžko usuzovat na to, jestli je to opravdu stejná chyba.

[Michal Kubeček]

(a mimo jiné to znamená, že jde-li o jiný driver, pak to téměř jistě není stejná chyba)

[NN]

Chtel jsem pouze ukazat na podobny problem..

[trubicoid2]

neco podobneho mi driv delala integrovana sitovka r8169, ale uz to mezitim v jadre opravili

nicmene se spatnym jadrem pomohlo vypnout Run-time PM u te sitovky, tedy neco jako: echo on > /sys/bus/pci/drivers/r8169/*/power/control

a jeste ty realteky jsou hodne citlivy na FW, zkontroluj, jestli mas aktualni

ethtool -i eth0

driver: r8169

version: 2.3LK-NAPI

firmware-version: rtl_nic/rtl8168e-2.fw

...

ls -l /lib/firmware/rtl_nic/rtl8168e-2.fw

-rw-r--r-- 1 root root 3920 Jan 20 10:01 /lib/firmware/rtl_nic/rtl8168e-2.fw

a z dotazu nechapu, jestli ty vytuhne realtek, via, nebo obe

[Milan Uhrák]

Tuhnou obě, fw mi to nezjišťuje (??)

ethtool -i eth0
driver: via-rhine
version: 1.5.1
firmware-version:
bus-info: 0000:00:12.0 
supports-statistics: no 
supports-test: no 
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

ethtool -i eth1
driver: r8169
version: 2.3LK-NAPI
firmware-version: 
bus-info: 0000:04:04.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

[trubicoid2]

nektery ty r8169 nepotrebuji fw

[NN]

Podle dohldani zde:

https://bugzilla.redhat.com/show_bug.cgi?id=377721

By mohl pomoct 'noapic' parametr a podival bych se po ovladacich via-rhine.

[Milan Uhrák]

Problém VIA je jistě možný, ale ona to dělá i nová gigabitka Realtek (PCI, ne PCIEx). Pak buď mají oba drivery podobný bug, nebo je problém hlouběji v systému -> chipset VIA ??. (zkusil jsem pci=noaer, teď se přenášejí data (34GB, tak výsledek chvíli potrvá). pak dám vědět.

Každopádně děkuji za zájem a pomoc váš všech.

Milan

aha .. 3.5GB a konec noaer nepomohl

[Milan Uhrák]

ještě bych dodal, že se výtuh nastane pouze při přenosu dat, pokud tam netlačím gigabajty, PC normálně funguje třeba celý den (neměřeno, nebyl důvod, prostě pokud nejdou giabajty dat, tak se ani jedna síťovka nezasekne). Zasekne-li se jedna, můžu hodit kabel do druhé, a ta funguje. Fakt je to divné.

OK, tak dáme noapic a uvidím

[Milan Uhrák]

jako vždy, trefa... Děkuji.

noapic způsobil, že se komplet 34G přeneslo.

Ještě počkám s opíjením, a párkrát to zopakuji. Ale tohle je poprvé. kdy se povedl přenos celého adresáře.

[Milan Uhrák]

aha, tak noapic při druhém kolečku kopírování selhal, a síťovka zase klekla

Tak vážně nevím, koupim jinou desku

[Ravensun]

Dobrý den,

Příjde mi, že jste řešil podobné chování, jakým já trpím na svém notebooku s Realtek RTL8168/81111 Gigabit Ethernet NIC. Problém je ten, že pokud nechci vyhodit celý notebook, tak nemůžu vyměnit základovku a tudíž pokud se to nepodaří vyřešit, asi budu muset dokoupit PCMCIA Ethernet síťovou kartu.

Jak se to chová u mě:

Cca 5minut po přihlášení o grafického prostředí to běží, pak se data přestanou odesílat a přijímat. Někdy pomůže vytažení kabelu a zase připojení kabelu do síťovky, někdy to nepomůže a musím to zkombinovat s nastavením "airplane mode" (takže zakázat veškerou komunikaci). Pokud ani to nepomůže, tak někdy na pár minut pomůže odhlášení a zase přihlášení.

Jsem BFU, takže kdybych uměl vypínat a zase zapínat síťovku v konsoli, tak bych sem napsal zda to má nějaký vliv nebo ne.

Příjde mi, že se to začalo objevovat od 3.10 verze jádra. A dost mě to štve.

Setkal se někdo další s podobným problémem?

[Heron]

Se síťovkami (realtek, intel) máme také své zkušenosti. Někde pomohl nový firmware, jinde se kompiloval novější kernel modul. Obecně zdá se, že pomáhá co nejnovejší jádro a vypnutí píčovin kolem šetření energie (ve switchích green lan, v pc potom usínání pci-e periférié, jedna serverová intelka se uměla vypnout tak, že už se neprobudila, dokud server neudělal poweroff / on).

[pavele]

Vzhledem k tomu, že se chystám kupovat síťovku, procházel jsem trochu zkušenosti na netu. Deset z devíti uživatelů všech OS doporučuje Intel a silně nedoporučuje Realtec, který někdy funguje, někdy funguje dobře a někdy nefunguje vůbec - viz problémy např. v CentOS 6.