Dotaz: eth0 unplugged

[HrabalVojta]

Po aktualizaci mi přestal fungovat eth0 hlásí unplugged i když je kabel připojen.

Odpovědi

[camel1cz]

Nemáte víc síťovek? Nezačal systém používat jinou? Mohly se prohodit např. eth0 a eth1.

Popř. je něco v v logu? Co říká "ifconfig -a"?

[HrabalVojta]

# ifconfig -a

eth0      Zapouzdření:Ethernet  HWadr 00:21:85:51:29:18  
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Přerušení:41 Vstupně/Výstupní port:0xc000 

lo        Zapouzdření:Místní smyčka  
          inet adr:127.0.0.1 Maska:255.0.0.0
          inet6-adr: ::1/128 Rozsah:Počítač
          AKTIVOVÁNO SMYČKA BĚŽÍ  MTU:16436  Metrika:1
          RX packets:74 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:0 
          RX bytes:4344 (4.2 KiB)  TX bytes:4344 (4.2 KiB)

wlan0     Zapouzdření:Ethernet  HWadr 00:21:5c:1f:35:c3  
          inet adr:10.4.10.35  Všesměr:10.4.10.39 Maska:255.255.255.248
          inet6-adr: fe80::221:5cff:fe1f:35c3/64 Rozsah:Linka
          AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST  MTU:1500  Metrika:1
          RX packets:838622 errors:0 dropped:0 overruns:0 frame:0
          TX packets:294023 errors:0 dropped:0 overruns:0 carrier:0
          kolizí:0 délka odchozí fronty:1000 
          RX bytes:993037521 (947.0 MiB)  TX bytes:32342946 (30.8 MiB)

[vencour]

Nikdy jsem nemusel ifup použít ... až do chvíle asi před 3 měsíci. Řešením bylo "ifup eth0". Dokonce ani ethtool neviděl link.

[HrabalVojta]

ifconfig eth0 up nefunguje

[vencour]

To je skript, "ifup eth0", viz např. CentOS a ifup.

[frr]

Zajímaly by mě výpisy dmesg, /proc/interrupts a lspci -vv. A co verze starého a nového jádra?

[HrabalVojta]

Přílohy:

• dmesg (30983 bytů)
• innterupts (1629 bytů)
• lspci_vv.txt (33625 bytů)

viz. přílohy. používám pořád to samé jádro

$ uname  -a
Linux vojta 2.6.36-gentoo-r5 #1 SMP Tue Feb 22 14:42:06 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux

[frr]

Mno... podle toho, že je to vidět v /proc/interrupts, soudím, že interface eth0 je "administratively up". Ale má v tabulce 0 interruptů, takže mu nechodí interrupty. A zrovna u r8168 už jsem zažil, že když nechodí interrupty, tak nenaskočí link - aspoň tohle se mi potvrdilo.

Všimněte si, že jako interrupt je použit MSI. Ve zmíněném předchozím případě mě právě message-signaled interrupty zachránily. Na tom stroji nebyl funkční local APIC, stačilo ho povolit ("lapic" na kernel cmdline = na konec řádky v bootloaderu) a síťovka se rozjela. Váš kernel si ale nestěžuje, že by měl Local APIC vypnutý... Takže bych možná zkusil pravý opak: pci=nomsi (další nápady: "pci=noacpi", nebo snad "irqpoll"; "pci=routeirq" patrně nepomůže).

Jinak mě ten rozbitý MSI zaráží. Vaše verze kernelu je poměrně kulatá a distro-specific. Pokud byste zkusil ještě jednu dvě nějaké stable vanilky s vysokým číslem na čtvrtém místě, tak by se dalo rozlišit, jestli je to bug v kernelu nebo nějaký platform-specific v hardwaru popř. BIOSu.

Terminologická poznámka: pokud zde používám zkratku MSI, myslím tím PCI-e Message-Signeled Interrupt, nikoli MicroStar International

[HrabalVojta]

Vaše verze kernelu je poměrně kulatá a distro-specific.

V debianu jsem zkoušel vanillku, ale neměl jsem s ní moc úspěchů, i když je debian vanilce nejblíž, měl jsem s ním pár problémů a nezkompiloval jsem s vlatním nastavením pouze z .config z distra lehce očesaný. Potřeboval bych manuál co, kdy a kde zapnout pro daný kus železa co podporuje atd. atd. mraky článků ale nic moc užitečného. a moje znalosti (angličtiny, linuxu) nejsou zas tak brilantní, abych mohl kompilovat vlastní jádro.

Na tom stroji nebyl funkční local APIC, stačilo ho povolit ("lapic" na kernel cmdline = na konec řádky v bootloaderu) a síťovka se rozjela. Váš kernel si ale nestěžuje, že by měl Local APIC vypnutý...

Měl jsem jistý problém s kernel a použil jsem vlatní nastavení akorát nenabootoval, takže jsem použil genkernel all a jádro nechal originální.

Takže bych možná zkusil pravý opak: pci=nomsi (další nápady: "pci=noacpi", nebo snad "irqpoll"; "pci=routeirq" patrně nepomůže).

Tomuhle řešení bych se zkusil vyhnout a spíš bych se podíval na konfigurace plugdev nebo /etc/net a /ect/runlevel nebo něco takového, protože mám plocit že jsem něco zkonil a solidně. Protože to fungovalo do doby zásahu do kernelu a přechodu na openRC. Nevím eth0 jestli fungoval předtím z livecd fungoval vždy. Jinde jsem ho nepotřeboval až nyní na konfiguraci routeru a nešel :-/. Stejně mi to rozhasilo wifi připojení, protože furt hlásí "settings network address viz Chybná wifi link zde z webu.

[frr]

S tím pci=nomsi to schválně zkuste. Nic za to nedáte. V bootloaderu hnete šipkou, aby zrušil timeout, vyberete obvyklý boot profile, pokud používáte grub tak dáte "upravit" nebo jak se tomu nadává, a připíšete si na konec řádku pci=nomsi. [Enter], bootuje - nikam nic nezapsal do trvalé konfigurace, Vámi přidaný argument platí jenom pro tenhle konkrétní boot. Máte šanci, že to vyprostí taky Vaši wifinu (Intel, taky jede přes MSI).

Pokud máte APIC, tak provoz bez MSI není velká tragédie.

Jsem si téměř jist, že /etc/bůhvíco naprosto nemá šanci mít vliv na chybné doručování interruptu (navíc MSI = nesdílí se). To je věc, která se nepovede někdy v ranných fázích bootování kernelu. /etc/blablabla se projeví až poté, co kernel mountne / a nastartuje init.

Taky nelze vyloučit, že Vám ta síťovka prostě hardwarově umřela pod rukama.

[asdads]

Soudruzi nekde udelali chybu. Toto jsem nasel https://bugzilla.kernel.org/show_bug.cgi?id=16293 pro Intel.

[HrabalVojta]

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

Jenže já používám tuhle síťovku.

[EnemyXP]

Měl jsem podobný problém, ale ten nastával při přepínání ve switchi s různými VLAN. Nakonec se to vyřešilo viz http://forum.ubuntu.cz/index.php/topic,54248.msg389720.html#msg389720

Popřípadě někde jsem našel ještě toto: Po uspaní počítača do RAM sa samočinne vypla služba network manager. Vyskúšaná je metóda po otvorení konzoly:

sudo service network-manager stop

sudo mv /var/lib/NetworkManager/NetworkManager.state /var/lib/NetworkManager/NetworkManager.moved

sudo service network-manager start

[HrabalVojta]

Usávání ani hibernaci nepoužívám protože nefunguje. A nikde nic nepřepínám. Prostě to nefunguje. Ale na tu webovku se juknu až se vrátím z oběda.

[HrabalVojta]

Zrovna mám podezření na dhcpcd. když ho spustím tak mi hodí tohle

# dhcpcd
dhcpcd[17270]: version 5.2.10 starting
dhcpcd[17270]: wlan0: rebinding lease of 10.4.10.35
dhcpcd[17270]: eth0: waiting for carrier
dhcpcd[17270]: wlan0: acknowledged 10.4.10.35 from 10.4.10.33
dhcpcd[17270]: wlan0: checking for 10.4.10.35
dhcpcd[17270]: wlan0: leased 10.4.10.35 for 10800 seconds
dhcpcd[17270]: forked to background, child pid 17412

a když ho pustím na wifi vypíše

# dhcpcd wlan0
dhcpcd[15643]: sending commands to master dhcpcd process

[frr]

"podezření"? Jako že dhcpcd za to všecko muže? DHCP software žije o vrstvu nebo dvě výš, než je Váš primární problém. Nezapřahejte kočár před koně.

V tom logu je vidět, že si dhcpcd korektně líznul adresu přes wifi (už ji zřejmě dostal posledně, tak ji teď jenom obnovil), ale ohledně eth0 říká, že nemá link.

Zaměřte se na to, že Vám nechodí interrupty od eth0, a vyzkoušejte pci=nomsi. Případně těch pár dalších cmdline argumentů, co jsem psal. V Gentoo je defaultní bootloader Grub, žejo?

http://www.gentoo.org/doc/cs/handbook/handbook-x86.xml?part=1&chap=10

Tady je návod přesně pro Vás, jak přidat zkusmo argument při bootu, aniž by se trvale zapsal do konfigurace - je to hned na první stránce pod nadpisem "1. Changing Boot Parameters Temporarily":

http://grumpymole.blogspot.com/2007/05/ubuntu-how-to-edit-grub-boot-parameters.html

Předpokladem je, že v /boot/grub/menu.lst (trvalá konfigurace Grubu) máte nějaký timeout = pár vteřin, než grub začne bootovat default boot profile = dá Vám šanci zasáhnout.

[HrabalVojta]

Se omlouvám jsem zapoměl zveřejnit výsledek "pci=noacpi noapic" nefunfuje pci=nomsi nefunguje bott z livecd funguje ...

[frr]

Zkuste "pci=noacpi", ale vynechte "noapic". APIC je užitečná věc, a dá se konfigurovat i přes MPS. Ale ono když je tam chyba, tak často ty tabulky jsou obě shodně blbě. Zkoušel jste "irqpoll"?

Když použijete "pci=nomsi" tak nefunguje boot z CD? Takže ovladač SATA HBA patrně naopak funguje *jenom* přes MSI... Ještě mě napadá, vypnout MSI selektivně v driveru r8169. Bohužel pro to není žádný parametr - musel byste šáhnout do zdrojáku. Koukám na aktuální zdroják:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/r8169.c

Momentálně na řádku 2743 se nachází toto:

.features = RTL_FEATURE_GMII | RTL_FEATURE_MSI,

(je to v sekci [RTL_CFG_1], která se týká čipu 8168). Ten řádek bych změnil na

.features = RTL_FEATURE_GMII,

... a pak samozřejmě rekompilovat a reinstalovat kernel (nebo aspoň ten modul).

Z jiného konce: není pro ten stroj k dispozici ke stažení update BIOSu? Tohle mi všecko ukazuje na bordel v BIOSových tabulkách co popisují zadrátování interruptů na motherboardu...

[HrabalVojta]

ne špatně jsem ořádkoval

nomsi - nefunguje
noapci apic - nefunguje
bott z cd (gentoo) - funguje

bios zde

[HrabalVojta]

ne špatně jsem ořádkoval

nomsi - nefunguje
noapci apic - nefunguje
bott z cd (gentoo) - funguje

BIOS jsem řešil zde bios zde

[frr]

No pokud po bootu z live CD síťovka funguje, tak bych hledal rozdíl mezi kernelem na live CD a na HDD. Nevím jestli dohledáte compile-time konfiguráky kernelu (.config), možná by byla zajímavá taky kompletní command lajna (po bootu je vidět někde v dmesg). V principu tenhle rozdíl naznačuje, že by to mohlo vyřešit jiné jádro.

[BigWrigley]

Mozna blbost, ale nepotrebuje tahle sitovka loadnout nejaky firmware? Podobne jako Broadcom karty...

[frr]

No nevěřil jsem tomu, nicméně ve zdrojáku v Linusově stromě skutečně vidím hned dvě klauzule MODULE_FIRMWARE. Patrně se to ale týká jenom dvou konkrétních variant RTL8168, zvaných D1 a D2. Viz funkce rtl_hw_phy_config(). Určující je zřejmě hardwarový atribut "MAC version" - pokud je ovladač zkompilován v debug režimu (snad -DDEBUG) tak se aktivuje funkce rtl_hw_phy_config(), která číslo "MAC version" při insmodu vytiskne do dmesg. Podle dříve dodaného dmesg se domnívám, že kolega má Eth čip RTL8168*B*, nikoli D - takže se ho firmware snad opravdu netýká.