Qualcomm Atheros AR8161- Statistiche e Centos 7

Un paio d'anni fa avevo avuto problemi con la scheda ethernet integrata "Qualcomm Atheros AR8161". Non c'erano driver nativi all'interno del kernel linux e andavano recuperati e ricompilati. Ne avevo parlato qui. Poi, da un certo punto in aventi, il driver alx è stato integrato nel kernel e tutte le varie distribuzioni linux che ho provato funzionavano correttamente.
E' sempre rimasto un problema, che puntale si ripresentava a ogni mia reinstallazione: sull'interfaccia ethernet associata alla scheda non sono visibili le statistiche, ovvero banalmente non si vede quanto traffico transita. Non me ne sono mai preoccupato più di tanto perchè, in ultima analisi, sul mio client non mi interessava.
Oggi però ho letto che la versione 3.14rc1 del kernel abilita le statistiche nel driver alx e che è possibile ricompilare quel driver anche per versioni del kernel precedenti.
https://bugzilla.kernel.org/show_bug.cgi?id=63401
http://www.spinics.net/lists/netdev/msg245607.html

Mi sono quindi incaponito nel cercare di abilitarle anche sul mio fedele Centos 7.1 con kernel 3.10.

Questa la situazione iniziale

Come si può vedere, col driver integrato nel kernel e richiamato come modulo da udev in fase di boot, non ci sono statistiche.

Scarico allora l'ultimo snapshot (coi driver di linux-next) di backports (ex compat-drivers, ex-ex compat-wireless) disponibile qui:
http://drvbp1.linux-foundation.org/~mcgrof/rel-html/backports/
o qui:
https://www.kernel.org/pub/linux/kernel/projects/backports/
Ciò che fornisce questo pacchetto è spiegato perfettamente nella breve descrizione  del sito
"About backports
We provide drivers released on newer kernels backported for usage on older kernels. Both daily snapshots based on linux-next, and stable releases based on Linux's stable releases are provided. The Linux drivers are automatically backported."

La procedura di installazione è stata resa identica alla ricompilazione di un kernel. La documentazione si può trovare qui:
https://backports.wiki.kernel.org/index.php/Documentation/packaging
Una volta scaricato e scompattato il pacchetto basterà digitare

andare ad abilitare il modulo che mi interessa, ovvero"Qualcomm Atheros AR816x/AR817x support":

effettuare il make e poi make install come root.

Questa procedura va ad installare il nuovo driver alx.ko e il suo nuovo modulo da cui dipende (compat.ko) in

Questo è il modo più intelligente possibile di procedere: Non va a sostituire il vecchio driver ma va a creare una directory "updates" che avrà la precedenza sul modulo da caricare (che abbia lo stesso nome) con modprobe.

(questo l'intero albero creato).

Fatto questo stacco il vecchio driver con "modprobe -r alx" e carico quello nuovo.

Controllo che il driver sia cambiato

e magicamente le statistiche iniziano a comparire

Tutto bene? Ma neanche per sogno....


Per sicurezza effettuo un bel reboot del sistema e, inspiegabilmente, le statistiche nuovamente scompaiono.

Ecco i miei tentativi (fessi) falliti e poi la banalissima soluzione

1)La prima cosa che penso è che, di default, venga richiamato il vecchio driver e non quello nuovo. Tutti i comandi che però posso usare per cercare di capire che driver viene utilizzato dopo un boot (lsmod, cat /prod/modules, modinfo alx)  mi dicono che è quello nuovo. Il modulo compat (dipendente dal modulo alx appena compilato) invece non viene caricato proprio.
Vado allora in /etc/modules-load.d/, creo un file chiamato alx.conf e ci scrivo
compat
alx

effettuo nuovamente il boot: questa volta compat c'è ma delle statistiche ancora niente.

2) Penso allora che ci sia qualcosa che non va in come udev carica per la prima volta il modulo.

Sembra corretto! Mi rieservo di morire addentrandomi nelle regole di udev solo quando sarò più disperato.

Nel mentre cerco di capire come udev riconosce un dispositivo e gli associa un driver: L'  interessante lettura di questo articolo (e le prove sul mio pc) mi porta via un'oretta ma non  offre spunti per la soluzione del problema.

http://www.linuxfromscratch.org/lfs/view/6.2/chapter07/udev.html

3)Tutto sembra confermarmi che il driver caricato sia quello nuovo ma, per essere veramente sicuro al 100% vado a eliminare il driver vecchio facendo un symlink di quello nuovo:

Effettuo un reboot e le statistiche ancora non ci sono.

4) Verifico che il modulo corretto sia stato digerito dal kernel correttamente e ne conosca anche le dipendenze.

di nuovo tutto ok, ma di statistiche neanche l'ombra.

5-SOLUZIONE)
Quando ho dato il "make install" dei driver l'installer mi ha scritto questo messaggio
"You may or may not need to update your initramfs, you should if
any of the modules installed are part of your initramfs. To add
support for your distribution to do this automatically send a
patch against "update-initramfs.sh". If your distribution does not
require this send a patch with the '/usr/bin/lsb_release -i -s'
("CentOS Linux") tag for your distribution to avoid this warning."

L'ignoranza non è una scusante ma credevo che nell'initramfs venissero caricati pochissimi driver utili all'avvio del sistema operativo, invece non è (più??) così.

Vado in /boot e uso il comando lsinitrd per elencare il contenuto dell'initramfs.

Con orrore vedo che contiene il vecchio driver: Ovviamente contiene il vecchio driver visto che non è stato aggiornato! Io però pensavo non lo contenesse proprio e che venisse caricato dal root file system...

Effettuo quindi un "backup" dell'initramfs attuale

lo rigenero con dracut non cambiandogli nome in modo da non dover modificare anche grub2.

Riguardo il suo contenuto con lsinitrd

BINGO!
Ci sono i driver nuovi (quelli della directory updates).

Effettuo un bel reboot e tutto funziona correttamente

Come nota a margine vedo che, all'interno dell'initramfs,  ci sono anche /etc/modprobe.d/* (per passare delle opzioni ai moduli, alias e blacklist) e /etc/modules-load.d/ (per caricare esplicitamente driver che udev non carica automaticamente): Immagino quindi che queste opzioni vengano sia lette in una prima fase nell'initiramfs e poi successivamente durante il boot nel root file system.

P.S: Al primo update del kernel con yum c'è da rifare tutta la procedura

P.P.S: Col kernel 3.10.0-229.20.1.el7.x86_64 funzionava tutto correttamente. Ora (01/2016) col kernel 3.10.0-327.4.4.el7.x86_64 da un sacco di errori in fase di compilazione e la voglia di scoprire che succede è davvero poca...

 

 

Print Friendly, PDF & Email