Problém s modulem e1000e a síťovým chipsetem Intel 82579V

Proč tento článek

Síťový chipset 82579V od společnosti Intel je dnes (2012) z pohledu aktuálnosti modulu e1000e v mnoha distribucích pořád ještě novinkou, ačkoliv začíná být masově nasazován například pro onboard síťové karty u základních desek Gigabyte (v mém případě deska X79-UD5 se socketem 2011). K údivu jsem zjistil, že distribuce jako jsou Debian Squeeze, OpenSuse 11.4, nebo Ubuntu 11.10 (zřejmě i další) obsahují poměrně staré verze tohoto modulu, jenž zaštiťuje ovladače pro gigabitové síťové karty. V případě debianu Squeeze a Ubuntu 11.4 je to shodně verze 1.2.7-k2 (někdy z roku 2010), přitom i modul e1000e se neustále vyvíjí a nyní je jeho nejnovější verze 1.10.6 z 30.3.2012. Faktem je, že síťová karta s chipsetem 82579V s těmito starými verzemi modulu e1000e prostě nefunguje. Tento článek tedy přináší úplné řešení tohoto problému.

Chování síťové karty s chipsetem Intel 82579V v kombinaci se starým distribučním ovladačem

Na první pohled se jeví jako bezproblémové. Pokud jste v situaci jako já, kdy zrovna instalujete nový systém, zřejmě si hned nevšimnete problému. Instalace ze síťových zrdcadel díky robustnosti TCP/IP komunikace nenechá nic znát. Až posléze kdy náhle příkazem ping necháte posílat ICMP pakety mezi vaším (ne nutně) 100Mbit routerem v místnosti a „problémovým“ strojem, zjistíte, že dochází ke ztrátám paketů (cca 30 - 60%). Příkazem ifconfig přitom nezjistíte nic zvláštního - hodnota errors u RX a TX packets je stále nulová. Jako nic neříkající se také jeví /proc/net/snmp. Tato fakta proto spíše ukazují na problémy někde v oblasti jádra nebo ovladače. Mohlo by se také zdát, že problém je hardwarový, ale není.

Jakou verzi ovladače aktuálně používá vaše problémová LAN karta zjistíte příkazem:

ethtool -i ethX

X - nahraďte číslem vašeho síťového zařízení

Řešení problému

Jediným řešením problému je kompilace vlastního ovladače, tedy celého modulu e1000e z poslední verze zdrojových kódů http://sourceforge.net/projects/e1000/files/e1000e%20stable/. Není mi znám jiný ovladač, který by s tímto chipsetem pod Linuxem dokázal pracovat. Proto je tato cesta jedinou. Řešení problému je dále demonstrováno pod Debianem Squeeze na 64 bitové platformě.

Instalace potřebných nástrojů pro kompilaci

Sadu nástrojů potřebných pro kompilaci nainstalujete následujícím příkazem:

apt-get install build-essential

Instalace hlavičkových souborů jádra

Hlavičkové soubory jádra budou nezbytné pro kompilaci modulu e1000e. Zadejte následující příkazy:

apt-get install linux-headers-2.6.32-5-amd64 linux-headers-2.6.32-5-common

Vytvoření symlinku linux v /usr/src

Předchozím krokem se hlavičkové soubory jádra nainstalovaly právě do /usr/src. Poměrně často se zde používá symlink linux, ukazující na adresář s aktuálním (posledním) jádrem. Přesuňte se do /usr/src a zadejte:

ln -s linux-headers-2.6.32-5-amd64 linux

Úprava souboru pm.h před kompilací

Toto je kámen úrazu. Pokud neprovedete úpravu souboru /usr/src/linux-headers-2.6.32-5-common/include/linux/pm.h kompilace v Debianu skončí chybami. Soubor pm.h proto otevřete v textovém editoru (vim, mcedit, …) a najděte v něm následující úsek kódu (v mém případě řádek 216):

#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
        .suspend = suspend_fn, \
        .resume = resume_fn, \
        .freeze = suspend_fn, \
        .thaw = resume_fn, \
        .poweroff = suspend_fn, \
        .restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif

Celý tento úsek bude třeba zakomentovat (v jazyce C blokovým komentářem viz syntaxe: /* zakomentonvaný kod /*), výsledek bude vypadat asi takto:

/*
#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
        .suspend = suspend_fn, \
        .resume = resume_fn, \
        .freeze = suspend_fn, \
        .thaw = resume_fn, \
        .poweroff = suspend_fn, \
        .restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
*/

Změny v souboru uložte.

Staženi poslední verze modulu e1000e

Zdrojové kódy naleznete na SourceForge. V mém případě jsem bezproblémový chod karty zajistil instalací verze 1.10.6-NAPI dostupné pod tímto odkazem: http://sourceforge.net/projects/e1000/files/e1000e%20stable/1.10.6/e1000e-1.10.6.tar.gz/download V době psaní tohoto článku to byla také poslední verze.

Rozbalení archivu

tar- xzvf e1000e-1.10.6.tar.gz

Kompilace vlastního modulu e1000e

Přesuňte se do adresáře se zdrojovými kódy modulu a do jeho podadresáře src. Zde by se měl nacházet Makefile. Zadejte:

make

Pokud kompilace neskončila chybou, modul nainstalujte:

make install

Pozn.: Soubor modulu od tohoto okamžiku můžete nalézt v adresáři: /lib/modules/2.6.32-5-amd64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko

Aktualizace iniciálního ramdisku

Pokud je tento modul přítomen i v iniciálním ramdisku, bude třeba jeho obraz aktualizovat. Jinak by došlo k zavedení původního - starého ovladače. Ačkoliv to není zřejmé, je součástí tohoto kroku také aktualizace zavislostí mezi moduly, jinak proveditelná příkazem depmod -a.

update-initramfs -u -k $(uname -r)

Stroj restartujte

Aby vše bylo 100%, stroj doporučuji restartovat. Nicméně nutné to není, mělo by stačit modul odebrat a znova zavézt.

Ověření, že síťová karta je spravována aktuálním ovladačem

Na závěr je dobré se ujistit, že síťová karta je spravována poslední verzí modulu e1000e, proto zadejte:

ethtool -i /dev/sdX

X - nahraďte číslem vašeho síťového zařízení

Řešení případných potíží, kdy modul způsobuje pád jádra nebo jej nelze hladce zavézt například z důvodu rozdílného vermagic

Vermagic je speciální řetězec obsahující několik informací - verzi jádra, platformu, info. o podpoře SMP, verzi kompilátoru. Tento řetězec má k dispozici jádro uvnitř sebe sama (od okamžiku jeho sestavení) a také je tento řetězec samostatnou součástí každého modulu. Pokud zavádíme modul (například příkazem modprobe), jehož vermagic se liší od vermagic jádra, je takový modul odmítnut. Důvod je zřejmý - zavádění modulu je potencionálně nebezpečná operace. Jádro proto odmítá moduly, které nejsou určeny pro právě používanou verzi kernelu/platformu/architekturu s jinou podporou SMP/jádro zkompilované jinou verzí kompilátoru. Zavedení takového modulu by mohlo způsobit nežádoucí chování jádra, nebo jeho pád.

Pokud provádíte předchozí kroky - sestavování modulu pro starší jádro (v mém případě opatchované jádro verze 2.6.18), může se stát, že modul má jiné vermagic, nebo se bude instalovat jinam. tyto problémy Vás nejspíše potkají, pokud je Vaše jádro nainstalované z rpm nebo deb balíku a přitom se zdrojové kódy téže verze jádra, které máte v systému, nepatrně liší v detailech. Tyto problémy nyní rozeberu a popíši jejich řešení:

Výsledný modul je nainstalován nečekaně jinam

Pokud po vykonání příkazu instalace modulu (make install) zjistíte, že modul se nečekaně nachází např. v /lib/modules/2.6.18-prep a přitom 2.6.18-prep zde nemá co dělat, neboť jádro tohoto názvu v systému není, jde o problém mezi Makefile zdrojových kódů modulu a souborem utsrelease.h zdrojových kódů jádra.

Tento problém lze vyřešit dvěma způsoby: První způsob je editace Makefile, přítomného vedle zdrojových kódů modulu, a vlastní definicí proměnné KVER, např. takto:

KVER := $(shell uname -r) 

Tento způsob ale nedoporučuji, neboť problém neřeší genericky. Jinými slovy, rozhodnete-li se v budoucnu do jádra přidat ještě neco nového formou modulu, budete tento problém řešit znova. Proto Makefile v tomto případě needitujte. Na místo toho se vyplatí editovat soubor utsrelease.h viz následující (pod)problém.

Vermagic výsledného modulu obsahuje nečekaně jinou verzi kernelu

Tento problém může nastat, pokud Vaše zdrojové kódy jádra (nikoliv modulu), přítomné v /usr/src/linux obsahují v souboru /usr/src/linux/include/linux/utsrelease.h v případě hodnoty UTS_RELEASE jinou verzi, než jaká odpovídá skutečné verzi jádra. V mém případě zde bylo uvedeno pouze 2.6.18-prep , coš jaksi úplně neodpovídá. Stačí proto upravit soubor utsrelease.h:

vim /usr/src/linux/include/linux/utsrelease.h

Makefile zdrojových kódů modulu použil k sestavení binárky jinou verzi kompilátoru gcc

Toto je, dle mého názoru, častý problém, který také v mém případě pokusu o kompilaci modulu pro starší jádro nastal. Moje jádro 2.6.18 bylo původně sestaveno kompilátorem gcc-4.1, kdežto modul se mi podařilo sestavit verzí gcc-4.3. Doinstaloval jsem proto chybějící gcc-4.1 do svého systému:

aptitude install gcc-4.1

Dále je třeba provézt editaci Makefile pro sestavení modulu e1000e, například editorem vim:

vim /usr/src/e1000e-1.10.6/src/Makefile

Makefile je třeba prohlédnout a alespoň rámcově pochopit, zejména tu část, kde se vybírá kompiler. V mém případě šlo o tento úsek kódu, kde se nastavuje proměnna CC:

# pick a compiler
ifneq (,$(findstring egcs-2.91.66, $(shell cat /proc/version))) 
CC := kgcc gcc-4.1 cc
else
CC := gcc-4.1 cc
endif

Tento úsek kódu prezentuji již jako upravený. Na řádcích se vyskytuje řetězec gcc-4.1, původně zde bylo jen gcc, což by znamenalo, že se použije kompilátor na nějž ukazuje symlink gcc (v Debianu se nachází v /usr/bin/gcc)

Touto úpravou by již mělo být zaručeno použití korektní verze kompilátoru. Nezaručuje však bohužel, že korektní verze kompilátoru bude použita v řetězci vermagic ve výsledném modulu !! Modul proto bude fungovat, pokud jej zavedeme násilně, ačkoliv budeme upozorněni na neshody ve vermagic.

modprobe -f e1000e

Modul kompiluji správnou verzí gcc, vermagic modulu ale stále obsahuje nečekaně jinou verzi

Toto je poslední problém bránící „hladkému“ zavedení modulu do jádra (bez parametru -f). Jeho kořen je v souboru Makefile, ale ne zdrojových kódů modulu, nýbrž zdrojových kódů jádra v /usr/src/linux !! Ano, je to opravdu tak.

Editujte proto soubor /usr/src/linux/Makefile:

vim /usr/src/linux/Makefile

A vyhledejte zde řádek (v mém případě číslo 284), kde se inicializuje proměnná CC:

CC    = $(CROSS_COMPILE)gcc

Tento řádek upravíme na tvar:

CC    = $(CROSS_COMPILE)gcc-4.1

Původní hodnota „gcc“ opět odkazuje na symlink v systému, který ukazuje na poslední verzi gcc přítomnou ve Vašem systému. Tato změna a následná rekompilace modulu způsobí korektní uvedení vermagic ve výsledném modulu e1000e. Ačkoliv jsme takto provedli změny ve zdrojových kódech jádra, není nutné jádro samotné rekompilovat.

Závěr

Pokud máte jakékoliv poznámky k tomuto článku, můžete se obrátit na naše diskuzní fórum http://forum.4smart.cz nebo na mou osobu emailem podpora[zav.]4smart.cz. Věřím, že tento postup usnadní život nejednomu ze čtenářů a uživatelů Linuxu v kombinaci s právě zmíněným chipsetem 82579V (nebo podobným) síťových karet.

J.Marák

 
problem_s_ovladacem_e1000e_a_sitovym_chipsetem_intel_82579v.txt · Poslední úprava: 2012/04/17 13:59 autor: root