Modifica ricompilazione installazione modulo del kernel

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » lun apr 27, 2015 11:34

Qualche post addietro avevi detto di aver testato la cosa anche su slackware 13.1.
Inoltre qui avevi fatto un test molto semplice ed efficace per capire cosa cerchi e cosa in definitiva trovi depmod:
viewtopic.php?f=2&t=38307&start=30#p342078

Se rifacessi lo setsso test su slackware 13.1, sempre che ti sia possibile, potremmo dire:
- se funziona out of the box sulla 13.1 e poi funziona anche sulla tua 14.1 allora il problema sta sul mio sistema.
- se invece sulla 13.1 non funziona allora il passaggio a "kmod" può essere l'imputato e magari da qualche parte nella 14.1 c'è qualche automatismo in più che manca invece sulla mia attuale 14.0

Non è detto però che facendo l'upgrade alla versione di kmod della 14.1 si risolva tutto, potrebbe anche essere da qualche altra parte l'inghippo...

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » lun apr 27, 2015 13:33

Io non penso che ci siano problemi sul tuo sistema, perché diversamente le opzioni passate a depmod non avrebbero avuto effetti.
Evidentemente qualcosa cambia da versione a versione: capire cosa e dove alla fine penso sia solo un esercizio di stile.

Piuttosto, prendendo sempre dal manuale: se tu i moduli li sposti da extra/ in updates/ cambia qualcosa?

Per la slack 13.1 ti faccio sapere stasera.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » lun apr 27, 2015 14:31

Ok, ho scaricato il modulo option con modprobe prima di fare il test consigliato.
Ecco cosa ho fatto e cosa sputa fuori...

Codice: Seleziona tutto

[root@darkstar build]# mkdir -v /lib/modules/3.19.4-hb_smp/updates
mkdir: directory "/lib/modules/3.19.4-hb_smp/updates" creata
[root@darkstar build]# cp -iv drivers/usb/serial/option.ko /lib/modules/3.19.4-hb_smp/updates/
"drivers/usb/serial/option.ko" -> "/lib/modules/3.19.4-hb_smp/updates/option.ko"
[root@darkstar build]# depmod -av `uname -r`|grep option.ko
/lib/modules/3.19.4-hb_smp/extra/option.ko needs "usb_wwan_write": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
/lib/modules/3.19.4-hb_smp/extra/option.ko needs "usb_serial_deregister_drivers": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko
[root@darkstar build]# rm /lib/modules/3.19.4-hb_smp/extra/option.ko
[root@darkstar build]# depmod -av `uname -r`|grep option.ko
/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko needs "usb_wwan_write": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko needs "usb_serial_deregister_drivers": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko

Quindi no...
O si imposta la directory in cui controllare se ci sono nuovi moduli "depmod.d" oppure nel mio caso depmod non trova il driver alternativo..
Come si vede, anche cancellando il modulo in extra... non viene data priorità a quello in updates.
vediamo cosa succede se cancello anche quello in-tree...

Codice: Seleziona tutto

[root@darkstar build]# mv -iv /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko /tmp/option.ko-in-tree-test
"/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko" -> "/tmp/option.ko-in-tree-test"
[root@darkstar build]# depmod -av `uname -r`|grep option.ko
/lib/modules/3.19.4-hb_smp/updates/option.ko needs "usb_wwan_write": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
/lib/modules/3.19.4-hb_smp/updates/option.ko needs "usb_serial_deregister_drivers": /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko

Spetta, adesso però la dir updates viene considerata...
Cioè non dice che non trova il modulo (spostato di proposito) ma trova e aggiunge alla lista quello della dir "updates":

Codice: Seleziona tutto

[root@darkstar build]# modinfo option|grep -v alias
filename:       /lib/modules/3.19.4-hb_smp/updates/option.ko
license:        GPL
description:    USB Driver for GSM modems
author:         Matthias Urlichs <smurf@smurf.noris.de>
depends:        usb_wwan,usbserial
vermagic:       3.19.4-hb_smp SMP mod_unload PENTIUMIII

In pratica, è solo un problema di priorità:
nel tuo caso la priorità viene data come ci si aspetterebbe alle versioni alternative di un certo modulo.
Invece sul mio sistema pare che sia prioritario il modulo "in tree"... Il chè ha poco senso... e solo modificando la configurazione di depmod, si può invertire questo comportamento...

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » lun apr 27, 2015 15:30

Ho "scoperto" che aggiungendo qualche "v" all'opzione --verbose "-v" depmod mostra alcune info molto interessanti per quel che riguarda il comportamento che assume nei confronti dei moduli esterni... E dei percorsi alternativi e non da considerare, nonchè della priorità da attribuirvi.
Il comando che ho lanciato è il seguente:

Codice: Seleziona tutto

depmod -avvv `uname -r` 2>/tmp/error-depmod.log 1>/tmp/output-depmod.log

Facendo un grep su "option.ko" ecco cosa viene fuori, vi riporto solo la parte attinente:

Codice: Seleziona tutto

grep -B10 -A10 'option.ko' /tmp/error-depmod.log|less

Codice: Seleziona tutto

DEBUG: try updates/option.ko (option)
DEBUG: comparing priorities of kernel/drivers/usb/serial/option.ko and updates/option.ko
DEBUG: search extra
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/updates/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
DEBUG: try aaa/option.ko (option)
DEBUG: comparing priorities of kernel/drivers/usb/serial/option.ko and aaa/option.ko
DEBUG: search extra
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/aaa/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
DEBUG: load symbols (3520 modules)

Insomma depmod "vede" le directories, extra, updates e aaa così come la dir "kernel" ovviamente.
Azzarda anche un controllo di priorità tra le varie subdir per capire quale versione del modulo option.ko considerare.
Però...
Alla fine decide sempre di dare priorità al modulo della dir "kernel", cioè quello "in-tree".
Se questo sia un comportamento predefinito nella versione di kmod che ho io, oppure risultato di qualche errore, bug ecc sinceramente non lo so...
Però almeno si è capito un po' di più cosa sta pensando depmod durante il suo aggiornamento dei moduli.

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » lun apr 27, 2015 16:30

E se updates - o extra - la metti dentro kernel/ che succede?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » lun apr 27, 2015 16:54

Posso anche provare, ma a naso non mi pare abbia molto senso...
Inoltre ricordiamoci che è il make modules_install che và ad installare i moduli esterni in extra e colloca quella directory esattamente dove l'abbiamo sempre trovata...
Comunque provo:

Codice: Seleziona tutto

[root@darkstar build]# mkdir -v /lib/modules/3.19.4-hb_smp/kernel/updates
mkdir: directory "/lib/modules/3.19.4-hb_smp/kernel/updates" creata
[root@darkstar build]# cp -iv drivers/usb/serial/option.ko /lib/modules/3.19.4-hb_smp/kernel/updates/
"drivers/usb/serial/option.ko" -> "/lib/modules/3.19.4-hb_smp/kernel/updates/option.ko"
[root@darkstar build]# depmod -avvvv `uname -r` 2>/tmp/error-depmod.log 1>/tmp/output-depmod.log
[root@darkstar build]# grep -B10 -A10 'option.ko' /tmp/error-depmod.log|less

Codice: Seleziona tutto

DEBUG: try kernel/drivers/usb/serial/option.ko (option)
DEBUG: comparing priorities of kernel/updates/option.ko and kernel/drivers/usb/serial/option.ko
DEBUG: search extra
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/updates/option.ko

Codice: Seleziona tutto

DEBUG: try updates/option.ko (option)
DEBUG: comparing priorities of kernel/updates/option.ko and updates/option.ko
DEBUG: search extra
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/updates/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/updates/option.ko
DEBUG: try aaa/option.ko (option)
DEBUG: comparing priorities of kernel/updates/option.ko and aaa/option.ko
DEBUG: search extra
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/aaa/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/updates/option.ko

Codice: Seleziona tutto

[root@darkstar build]# modinfo option|grep -v alias
filename:       /lib/modules/3.19.4-hb_smp/kernel/updates/option.ko
license:        GPL
description:    USB Driver for GSM modems
author:         Matthias Urlichs <smurf@smurf.noris.de>
depends:        usb_wwan,usbserial
vermagic:       3.19.4-hb_smp SMP mod_unload PENTIUMIII

In effetti funziona...
Il modulo piazzato nella dir updates interna alla dir "kernel" è prioritario per depmod rispetto a quello "in-tree".
Però come dicevo, allora perchè mai make modules_install non va ad installare il modulo nuovo lì piuttosto che fuori dalla dir kernel?
È proprio quel comando che crea la dir extra esterna alla subdir "kernel"...

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » lun apr 27, 2015 17:12

Guarda, se funziona il problema non c'è. Tu mi dirai: ma perché da te prende tutto quello che sta nella radice dei moduli del kernel? Già, perché sulla slack14.1 è proprio così. Che la directory si chiami pippo, pluto o topolino poco importa:

Codice: Seleziona tutto

depmod: DEBUG: comparing priorities of pluto/option.ko and kernel/drivers/usb/serial/option.ko
depmod: DEBUG: Ignored lower priority: /lib/modules/3.19.5-smp/kernel/drivers/usb/serial/option.ko, higher: /lib/modules/3.19.5-smp/pluto/option.ko


Sul perché di questi differenti comportamenti non ti so dire, ma questo ad esempio è il config che esce col pacchetto i686 di arch:

Codice: Seleziona tutto

#
# /usr/lib/depmod.d/search.conf
#[/url]

search updates extramodules built-in

Della serie: tra vedere e non vedere, forzo brutalmente il search.

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » lun apr 27, 2015 17:33

Aggiungo:
siccome kmod richiede per la compilazione i (linux)kernel-headers, probabile che il differente comportamento dipenda da questo.
Ovvero, non dalla versione di kmod, ma dalla versione dek kernel linux utilizzato per generare il pacchetto kernel-headers.

Ma anche questo prendilo con le pinze.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » lun apr 27, 2015 17:40

Ho capito...
Cioè, non sappiamo dare una risposta definitiva, però almeno ho capito come posso attuare una procedura per editare un modulo e ricompilare solo quello forzando l'uso della nuova versione attraverso la configurazione di depmod.d.

Come hai già detto anche tu andare oltre nell'indagine è pura curiosità. L'utilità è scarsa.
Tuttavia, senza fretta e senza impegno, se qualcuno sa rispondere sarebbe una cosa gradita mettere il punto alla faccenda, almeno per soddisfare la curiosità e dare un senso all'intero topic! :lol:

Se riesci Rik a fare la prova di cui abbiamo parlato anche su slack-13.1 leggerò volentieri il risultato.

Infine se qualcun'altro come me utilizza ancora la slackware-14.0 e vuole testare il comportamento il test è molto facile, non serve nulla, neanche i sorgenti del kernel. Si fà in pochi minuti incluso il post dei risultati. Sarebbe una controverifica interessante per togliermi il dubbio che non abbia io qualche settaggio strano attivo.

In ogni caso grazie a chi ha partecipato alla discussione e mi ha dato una mano a vederci più chiaro...

EDIT:
Stiamo scrivendo insieme...
No sinceramente non l'ho capita sta cosa dei kernel-headers.
Io attualmente ho in uso un kernel diverso da quello di slackware-14.0...
Per cui immagino che se vado a compilare qualcosa mi appoggerò agli headers del kernel in uso...
O forse intendi che il pacchetto kmod che sto usando è stato creato appoggiandosi ai kernel headers del 3.2.45?
Però non capisco il nesso sinceramente.

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » lun apr 27, 2015 17:55

joe ha scritto:O forse intendi che il pacchetto kmod che sto usando è stato creato appoggiandosi ai kernel headers del 3.2.45?

Esatto.
Il pacchetto kernel-headers è generato dai sorgenti del kernel che esce con la distribuzione - butta un occhio in /var/log/packages/kernel-headers-*.
Che dipenda da questo è comunque una pura supposizione. Sicuro è che kmod ha bisogno di quei sorgenti per compilare, e va a "pescarli" proprio dal pacchetto kernel-headers.

Quanto a slack 13.1, il comportamento è altrettanto bizzarro:

- extra/, updates/, pluto/ hanno priorità alta rispetto a kernel/;

- aaa/ invece no, ma abc/ sì.

Se tu in tutto questo ci vedi qualcosa di razionale fammi un fischio :)

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » mar apr 28, 2015 0:03

Ciao, no guarda... dopo tanti anni sono sempre più convinto che informatica e razionalità spesso s'accoppiano mal volentieri! :lol:

Dal canto mio posso provare ad allargare il cerchio e coinvolgere nel discorso anche gli utenti di linuxquestions, nonostante il mio inglese macheronico spesso ho ricevuto aiuto e spiegazioni che mi hanno permesso di capire "misteri" come questo.

Che vuoi che ti dica... proviamo!
Anche se a livello di utilità non è che mi cambi la vita perchè con l'impostazione di "depmod.d" la directory "extra" popolata correttamente dal kernel viene regolarmente digerita. Siccome ho editato il sorgente del modulo option per tentativi (non sono un programmatore, non so il C, non ho mai capito nulla di oggetti e robe simili...) bè ho trovato molto speditiva la compilazione del singolo modulo.
In pratica:
- edito
- ricompilo
- reinstallo
- testo
Il tutto con tempi ben inferiori alla compilazione dell'intero tree già lavorato che mi consentono anche errori grossolani di editing... ;)

PS.
Faccio notare anche un'latra cosa, ora sto compilando dai sorgenti non lavorati (ho il backup anche di quelli lavorati ovvio...): tra le varie prove avevo dato anche un "make mrproper" e "make distclean", quindi ho ripulito tutto.
Poi però dal backup mi è bastato ricopiare:
- il config relativo alla prima compilazione totale (quella durata ore e ore)
- il file "Module.symvers" anch'esso generato dalla compilazione totale
- poi si danno i soliti... "make prepare", "make modules_prepare".
- a questo punto si può passare all'editing del sorgente del modulo seguito dalla ricompilazione ed installazione come già visto.

Offtopic: Tanto per la cronaca, qualche progresso con il modulo option l'ho fatto.
Il risultato (per me e le mie modeste capacità direi notevole...) è che ora all'inserimento della chiavetta, "option" si aggancia correttamente alle sole interfacce di sua competenza (che da quanto ho capito sono quattro, dalla 2 alla 5 , lasciando ad esempio le prime due e l'ultima orfane.
In questo modo queste ultime vengono agganciate dai moduli appropriati:
- la 0 e la 1 dai cdc_mbim (per usare la chiavetta in modalità "direct ethernet" e sfruttare l'interfaccia di rete associata "wwan*" e il device "/dev/cdc_wdm*" (sto testando mbim-network, anche se fin'ora senza completo successo, ma sono fiducioso).
- la numero 6 invece viene presa in consegna dal driver usb_storage

Possibile-TODO:
fare in modo che sia ancora visibile il dispositivo simil CD... "/dev/sr*" che viene eliminato da usb_modeswitch per far si che la chiavetta appaia come modem.
Non so se per questa Olicard-300 sia possibile o se sia esclusiva la presenza del dispositivo Zero-CD e della funzionalità come modem.
Però per l'altra chiavetta che ho sottomano, una Huawei-E353 questo avviene... Cioè alla fine sono contemporaneamente disponibili sia il device /dev/sr* associato, oltre alla funzionalità di modem dialup e a quella di direct ethernet (wwan|/dev/cdc_wdm*, per questo device si deve usare il driver qmi_wwan e qmi-network per connettersi e funziona, anche ora vi sto scrivendo collegato così: niente pppd, wwan0 configurata in /etc/rc.d/rc.inet1.conf).

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » mar apr 28, 2015 11:32

Comunque sia la faccenda, il fatto che i pacchettizatori di arch si siano preoccupati di predisporre un config che sovrascrive l'ordine di priorità delle directory, mi fa concludere che questi comportamenti "anomali" sono noti. A riprova di ciò non solo aggiungono 'extramodules' - che se non ricordo male è un collegamento simbolico a qualcosa che sta in '/lib/modules' - ma si "preoccupano" pure di specificare 'updates', che di default dovrebbe funzionare di suo.

Piuttosto per curiosità: se dai

Codice: Seleziona tutto

kmod -V
cosa salta fuori?

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 2923
Iscritto il: ven apr 27, 2007 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda joe » mer apr 29, 2015 20:08

In questi ultimi giorni non riuscivo a raggiungere il sito Slacky.eu...
Rispondo solo adesso:

Codice: Seleziona tutto

# kmod -V
kmod version 9


In realtà però ho fatto un errore in un post precedente e la cosa sembra funzionare di suo se il modulo alternativo viene messo in "updates".
Copio il messaggio che avevo scritto l'altro giorno e che poi non ero riuscito a postare causa down del sito.

"
Mentre scrivevo il messaggio da posstare su linuxquestions, mi sono accorto che ho riportato per distrazione un'informazione errata.
Ieri Rik70 mi aveva suggerito di provare a copiare il modulo nell dir:

Codice: Seleziona tutto

/lib/modules/$(uname -r)/updates


In qualche modo devo aver ommesso qualcosa o semplicemente non mi ero accorto che funzionava...
Adesso ho riprovato e grazie al DEBUG appare chiaro che il modulo in "updates" risulta prioritario rispetto a quello "in-tree".
In qualche modo tutto ciò viene accennato nel man depmod.conf, anche se sul mio sistema di tale pagina di manuale non vi è traccia.
Ad ogni modo, ho eliminato il files di configurazione di depmod, adesso non vi sono:
- /etc/depmod.d/*conf
- /lib/depmod.d/*conf
- /run/depmod.d/*conf

In pratica depmod dovrebbe seguire il suo comportamento di default.

Il modulo option è presente in 3 subdirs diverse:

Codice: Seleziona tutto

[root@darkstar build]# find /lib/modules/`uname -r` -name option.ko
/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
/lib/modules/3.19.4-hb_smp/updates/option.ko
/lib/modules/3.19.4-hb_smp/extra/option.ko


Lanciando depmod in debug mode e greppando su option...

Codice: Seleziona tutto

depmod -avvvv `uname -r` 2>/tmp/error-depmod.log 1>/tmp/output-depmod.log
grep -A6 'option.ko' /tmp/error-depmod.log


Codice: Seleziona tutto

DEBUG: try kernel/drivers/usb/serial/option.ko (option)
DEBUG: add 0x9a79370 kmod=0x9a79330, path=/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
.....
--
DEBUG: try updates/option.ko (option)
DEBUG: comparing priorities of kernel/drivers/usb/serial/option.ko and updates/option.ko
DEBUG: search updates
DEBUG: priorities: built-in: -1, old: 0, new: -1
DEBUG: Replace lower priority kernel/drivers/usb/serial/option.ko with new module updates/option.ko
DEBUG: del 0x9a79370 kmod=0x9a79330, path=/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
DEBUG: free 0x9a79370 kmod=0x9a79330, path=/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
DEBUG: add 0x9a79330 kmod=0x9a79370, path=/lib/modules/3.19.4-hb_smp/updates/option.ko
DEBUG: try extra/option.ko (option)
DEBUG: comparing priorities of updates/option.ko and extra/option.ko
DEBUG: search updates
DEBUG: priorities: built-in: -1, old: -1, new: 0
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/extra/option.ko, higher: /lib/modules/3.19.4-hb_smp/updates/option.ko
......
--
DEBUG: ignoring /lib/modules/3.19.4-hb_smp/updates/option.ko: no symbols
--
DEBUG: do dependencies of /lib/modules/3.19.4-hb_smp/updates/option.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_write /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol usb_autopm_put_interface
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_suspend /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_close /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol find_first_bit
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol kfree
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol tty_port_tty_hangup
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol kmem_cache_alloc_trace
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_port_probe /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol usb_submit_urb
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_tiocmget /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_chars_in_buffer /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_write_room /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol usb_control_msg
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol mcount
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol dev_err
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_port_remove /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_serial_deregister_drivers /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol jiffies
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_resume /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol usb_autopm_get_interface
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_dtr_rts /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_open /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol find_next_bit
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko needs (U) unknown symbol kmalloc_caches
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_ioctl /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_serial_register_drivers /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko
DEBUG: /lib/modules/3.19.4-hb_smp/updates/option.ko depends on usb_wwan_tiocmset /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
--
DEBUG: free 0x9a79330 kmod=0x9a79370, path=/lib/modules/3.19.4-hb_smp/updates/option.ko


Codice: Seleziona tutto

[root@darkstar build]# modinfo option|grep -v alias
filename:       /lib/modules/3.19.4-hb_smp/updates/option.ko
license:        GPL
description:    USB Driver for GSM modems
author:         Matthias Urlichs <smurf@smurf.noris.de>
depends:        usb_wwan,usbserial
vermagic:       3.19.4-hb_smp SMP mod_unload PENTIUMIII

[root@darkstar build]# modprobe -v option
insmod /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usbserial.ko
insmod /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/usb_wwan.ko
insmod /lib/modules/3.19.4-hb_smp/updates/option.ko


In conclusione, la dir "updates" sembra avere priorità alta...
invece la dir "extra" (cioè quella dove kbuild piazza i moduli esterni di default) non pare essere prioritaria nei confronti del percorso "in-tree".

Per scrupolo elimino "updates" e lancio di nuovo depmod.

Codice: Seleziona tutto

[root@darkstar build]# find /lib/modules/`uname -r` -name option.ko
/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
/lib/modules/3.19.4-hb_smp/extra/option.ko
[root@darkstar build]# depmod -avvvv `uname -r` 2>/tmp/error-depmod.log 1>/tmp/output-depmod.log

Codice: Seleziona tutto

DEBUG: try kernel/drivers/usb/serial/option.ko (option)
DEBUG: add 0x9702370 kmod=0x9702330, path=/lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko
---
DEBUG: try extra/option.ko (option)
DEBUG: comparing priorities of kernel/drivers/usb/serial/option.ko and extra/option.ko
DEBUG: search updates
DEBUG: priorities: built-in: -1, old: -1, new: -1
DEBUG: Ignored lower priority: /lib/modules/3.19.4-hb_smp/extra/option.ko, higher: /lib/modules/3.19.4-hb_smp/kernel/drivers/usb/serial/option.ko


Quindi ho conferma della fallita priorità di "extra" rispetto alla versione "in tree".
Faccio anche notare che vi è una riga del DEBUG che dice "search updates", potrebbe riferirsi alla ricerca (di default) nella dir "updates", che al momento però non esiste perchè l'ho rimossa di proposito... Però depmod tenta di controllarla per verificare se dentro vi sia qualcosa da caricare con priorità.

Tutto ciò non cambia di molto le cose:
Si vorrebbe che il comportamento di default del processo di compilazione/installazione del kernel (kbuild) e dei suoi moduli coincidesse col default di depmod. Ovvero, viso che il kernel installa in "extra" i moduli esterni, depmod dovrebbe dare priorità alta a ciò che trova in "extra".
Invece nel mio caso sembra che abbia priorità alta solo la subdir "updates".

Sul tuo sistema rik saltava fuori la riga con "DEBUG: search updates"?
Pur non avendo alcuna subdir chiamata così?
"

Avevo scritto questo..
Ad ogni modo ho messo lo stesso messaggio all'incirca anche su LQ:
http://www.linuxquestions.org/questions ... 175541003/

Per ora fa parte dei "Zero Reply Threads"...
Ma come abbiamo già detto e ripetuto, l'importante è che in qualche modo funzioni... di default o mettendoci un minimo le mani! ;)
Se poi si capisce anche il verso di come funziona tanto meglio, ma se nessuno ci capisce sopravviveremo lo stesso! :lol:

rik70
Master
Master
Messaggi: 1943
Iscritto il: gio mar 10, 2011 9:21
Slackware: 14.2
Kernel: 4.18
Desktop: Xfce 4.12
Distribuzione: archlinux

Re: Modifica ricompilazione installazione modulo del kernel

Messaggioda rik70 » gio apr 30, 2015 18:46

Allora:

- sì, la directory updates viene scansionata anche se non c'è;

- per il manuale:

Codice: Seleziona tutto

man depmod.d


Quanto al resto, se proprio ti vuoi togliere ogni dubbio e incertezza, la questione andrebbe girata più propriamente agli sviluppatori. Se ti fai un giro su git.kernel.org trovi pure le mail.

Diversamente, come dicevo prima, la prova del "cuoco" è compilare ed installare la versione 15 di kmod e vedere se cambia qualcosa.