Compilare il Kernel

[Emalele1688]

Allora, ti posto l'output di dmesg a due messaggi prima del problema powernow e 5 messaggi dopo ... mi sembra di intuire che i valori a sinistra è il tempo impiegato tra un operazione e l'altra ... Giusto? Se così fosse stiamo parlando di millesimi di secondi ....

0.947324] NET: Registered protocol family 17
[ 0.947345] Registering the dns_resolver key type
[ 0.947368] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2 cpu cores) (version 2.20.00)
[ 0.947414] powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0xa
[ 0.947416] powernow-k8: 1 : fid 0xe (2200 MHz), vid 0xc
[ 0.947418] powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xe
[ 0.947420] powernow-k8: 3 : fid 0xa (1800 MHz), vid 0x10
[ 0.947422] powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12
[ 0.947447] powernow-k8: limiting to cpu 0 failed
[ 0.947493] powernow-k8: limiting to cpu 0 failed
[ 0.947638] PM: Hibernation image not present or could not be loaded.
[ 0.947649] registered taskstats version 1
[ 0.947941] Magic number: 11:728:451
[ 0.948063] rtc_cmos 00:02: setting system clock to 2011-01-14 22:24:15 UTC (1295043855)
[ 0.948066] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found

[Gimli[2BV!2B]]

Esatto, a sinistra hai il tempo in secondi trascorso dal caricamento del kernel in memoria: passano 2 decimi di millesimo di secondo abbondanti a cavallo degli errori, direi che è trascurabile

[ezln]

Originariamente inviato da Gimli[2BV!2B]

Non ricordo con quale importanza erano classificati.
Se si tratta di errori non c'è modo di mascherarli, tranne commentandoli dai sorgenti o utilizzando uno splash screen.
Se si tratta di warning dovrebbero sparire insieme a tutti gli altri messaggi utilizzando passando il parametro quiet al kernel, in Grub.

Naturalmente si cerca di ottenere il meglio.
Per attivare le ottimizzazioni corrette per la propria CPU e le ottimizzazioni classiche (-O2 -fomit-frame-pointer e altre piccolezze) occorre impostare queste voci ([ ] evidenzia opzioni da disattivare):

General setup  --->
    [ ] Optimize for size
    [*] Optimize trace point call sites

Processor type and features  --->
    [ ] Support for extended (non-PC) x86 platforms
    [*] Single-depth WCHAN output
        Processor family (SCEGLIERE LA FAMIGLIA CORRETTA)  --->
    [ ] Generic x86 support

Kernel hacking  --->
    [ ] Compile the kernel with frame pointers
    [*] Allow gcc to uninline functions marked 'inline'

Ricorda di fare backup delle configurazioni buone!

Ciao.
A parte i soliti complimenti a Gimli, un drago da spavento, e pure ad Emalele perchè non demorde e impara a vista d'occhio, volevo chiedere una cosa: nel quote, Gimli, dici "...attivare le ottimizzazioni corrette per la propria CPU e le ottimizzazioni classiche (-O2 -fomit-frame-pointer e altre piccolezze) occorre impostare queste voci...etc etc"; se io poi su una gentoo imposto determinate CFLAGS in make.conf -ad esempio non mi interessa il -fomit-frame-pointer- e nel kernel sono abilitate le opzioni di cui parli, che accade? Il compilatore come si comporta?
Boh magari è una domanda stupida...

[Gimli[2BV!2B]]

@ezln le impostazioni del kernel vincono.
La compilazione del cuore del sistema offre meno possibilità di personalizzazione sotto questo punto di vista ed è basata sulle impostazioni del .config.
Ad esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Il make.conf vale solo per gli strumenti della distribuzione: portage, ebuild, ecc...

[ezln]

Originariamente inviato da Gimli[2BV!2B]

@ezln le impostazioni del kernel vincono.
La compilazione del cuore del sistema offre meno possibilità di personalizzazione sotto questo punto di vista ed è basata sulle impostazioni del .config.
Ad esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Il make.conf vale solo per gli strumenti della distribuzione: portage, ebuild, ecc...

Grazie! Ricevuto e capito. Chiaro come sempre, Gimli. LOL

[jeremy.83]

Mi spiace sporcare il thread, ma mi aggrego ai complimenti a Gimli, è uno dei migliori utenti attivi al momento sul forum, tanto di cappello

[darkbasic]

Originariamente inviato da Gimli[2BV!2B]

@ezlnAd esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Compila compila, dovresti vedere le ottimizzazioni assurde che usano i ragazzi di linuxdna con il compilatore icc
Se sei interessato alle performance quello è il kernel più veloce che puoi ottenere, ma è talmente tanto infarcito di bug che io ho lasciato perdere (sono perfino tornato alla toolchain di stable )

[Gimli[2BV!2B]]

Grazie jeremy.83

@darkbasic è vero, ricordo di averne letto. Avevo pure avuto voglia di provarlo, naturalmente, ma l'AMD Athlon XP che avevo è stato lo scoglio che non mi ha nemmeno fatto partire (dovevo usare un'icc discretamente vecchio per problemi SSE e applicare le patch al compilato per far funzionare il codice ottimizzato).
Ci credo che sia ingestibile, già molti programmi normali si rompono con icc, immagino il kernel.

Ho fatto un giro ora sul sito (ora ho un Pentium IV ). Hanno rinominato d'ufficio l'amd64 in intel64? Mi sembra di capire che il progetto sia un po' in stallo al momento.

[darkbasic]

Sì è un po in stallo effettivamente...

[Emalele1688]

LinuxDNA cosa sarebbe? (Per curiosità)
Mi sembra di capire che sia un progetto riguardante l'ottimizzazione del Kernel e la compilazione di questo con il compilatore Intel ...

[Gimli[2BV!2B]]

LinuxDNA è (stato?) un progetto per rendere il kernel Linux compilabile utilizzando il compilatore proprietario Intel icc.
Per raggiungere l'obiettivo hanno dovuto modificare discretamente il makefile, oltre ad andare incontro a svariati errori dovuti al fatto che i sorgenti sono stati scritti per gcc (icc e gcc son due bestie completamente diverse).

I compilatori Intel hanno la fama di essere tra i più efficienti (10÷40%), oltre ad essere noti per produrre codice che si comporta in modo diverso a seconda della cpu che lo esegue.
Se la cpu è Intel viene eseguito il codice ottimizzato con le estensioni Intel (dalle SSE in avanti), altrimenti viene usato quello normale.
Questo anche se la cpu dichiara di supportare queste istruzioni: si tratta di un semplice test sul nome del produttore.

Se si vogliono eseguire decentemente i binari prodotti con icc su macchine non Intel occorre patchare o i binari generati o i binari del compilatore stesso per produrre direttamente programmi buoni (patchando il compilatore si va contro la sua EULA).

Tirando le somme: il compilatore Intel può essere definito lo stato dell'arte dei compilatori, però contiene limitazioni enormemente discutibili e praticamente tutto il codice open source è stato scritto per gcc.

[niki89]

ciao ragazzi io ho un portatile con i3 330M con ati 5650 una volta aggiornai il kernel però mi ritrovai con i driver non compatibili.
C'e un modo per raggirare questa cosa?

[Gimli[2BV!2B]]

Cosa vuol dire "driver non compatibili"?
Periferiche che non funzionavano?
Kernel panic all'avvio?

Che distribuzione?
Ma, soprattutto, kernel di distribuzione o compilato? Tu scrivi un generico "aggiornamento".

[Emalele1688]

Una perplessità che mi è giunta in mente, forse anche stupida...
Ma se io compilo un Kernel vanilla usando il file .config del Kernel Ubuntu; Per intenderci compilo il Kernel vanilla 2.6.37 ed all'interno dei sorgenti inserisco il .config proveniente dall'ultimo kernel di Ubuntu 10.10 (dovrebbe essere il 2.6.35.24), una volta che do "make oldconfig", poichè compilo un kernel vanilla le voci di configurazione appartenenti solamente al Kernel di Ubuntu (Tutto ciò che è stato aggiunto dagli sviluppatori di Ubuntu nel Kernel) vengono automaticamente rimosse ??

[Gimli[2BV!2B]]

Tutte le opzioni che non hanno corrispondenza vengono rimosse e tutte le novità vengono proposte.

Il make oldconfig parte dalle opzioni disponibili nei sorgenti e imposta i valori che trova nel .config, dopodiché chiede che fare con le opzioni che non hanno ricevuto un valore.
Una volta raccolti tutti i parametri sovrascrive il .config

[*andre*]

ciao ragazzi
uppo la discussione per avere un chiarimento.. stavo compilando l'ultima versione del kernel(2.6.37) però mi è finito lo spazio sul disco

la situazione della partizione root è questa
cioè ho lasciato 15GB..

è possibile che mi tenga più di 5 GB la versione compilata? (compresso il source code pesa 70mb...)

poi una cosa non mi torna.. li mi segnala la partizione home piena.. ma la home la ho montata in un'altra partizione da 50 GB

consigli?

[Gimli[2BV!2B]]

@*andre*, anche il kernel più completo non penso possa occupare più di 1÷1,5 GiB:

kwankey ~# du -sh /usr/src/linux-2.6.37-ck
579M    /usr/src/linux-2.6.37-ck

Riguardo alla segnalazione sulla /home posso solo dirti che in Kde non ho mai avuto messaggi errati...

Che dice df -h ?

[darkbasic]

Confermo gli 1.5 GB

[*andre*]

Originariamente inviato da Gimli[2BV!2B]

@*andre*, anche il kernel più completo non penso possa occupare più di 1÷1,5 GiB:

kwankey ~# du -sh /usr/src/linux-2.6.37-ck
579M    /usr/src/linux-2.6.37-ck

Riguardo alla segnalazione sulla /home posso solo dirti che in Kde non ho mai avuto messaggi errati...

Che dice df -h ?

Originariamente inviato da darkbasic

Confermo gli 1.5 GB

Grazie per le risposte..
"du -sh" come nel tuo tag code mi dava 5GB
invece df -h:

andrea@andrea-Mint ~ $ df -h
File system            Dim. Usati Disp. Uso% Montato su
/dev/sda5              11G  4,3G  5,3G  45% /
none                  2,0G  328K  2,0G   1% /dev
none                  2,0G  656K  2,0G   1% /dev/shm
none                  2,0G  316K  2,0G   1% /var/run
none                  2,0G     0  2,0G   0% /var/lock
/dev/sda6              46G  5,5G   38G  13% /home

adesso l'ho liberato un pò visto che restavano 15mb liberi

ho fatto la prova sia con kernel vanilla (2.6.37) sia con l'ultima versione per Mint 10 (2.6.35-24) ma niente.. sicuro che sono io che sbaglio qualcosa, ma oltre a esermi letto tutta questa discussione mi sono documentato su debianizzati..
Questi sono i passi che ho fatto l'ultima volta con il kernel della distribuzione:

1. Scarico con apt l'ultimo kernel in .deb
2. vado in /usr/src/LinuxYYZZ
3. ci copio la patch bfs e la applico con il comado in prima pagina:
   

   patch -d linux-2.6.35-24 -p1 < 2.6.35-10-sched-bfs-363.patch

4. copio la configurazione da /boot/
5. make oldconfig , in cui la unica diferenza che mi indica è lo scheduler bfs e un'altra cosa (sarà la differenza tra la versione di kernel che ho ora (2.6.35-22) con la 2.6.35-24 disponibile nei repository
6. da make menuconfig tolgo solo l'initrd e compilo i driver ext3-4
7. dopo visto che vorrei un .deb lancio:
   

   CONCURRENCY_LEVEL=3 fakeroot make-kpkg --append-to-version -"nomepersonalizzato" --revision=1 kernel_image kernel_headers

[Gimli[2BV!2B]]

Mah, 5 GiB mi sembran proprio troppi. AMD64, per caso?

Per il resto l'unico punto che non mi torna è il 6:

Originariamente inviato da *andre*

da make menuconfig tolgo solo l'initrd e compilo i driver ext3-4

Devi integrare anche i driver IDE/PATA o SATA del tuo chipset e assicurarti che siano integrate le parti SCSI necessarie:

Device Drivers  --->
    SCSI device support  --->
        <*> SCSI disk support
        [*] Asynchronous SCSI scanning
    <*> Serial ATA and Parallel ATA drivers  --->
        [*] SELEZIONARE EVENTUALI FUNZIONALITÀ AGGIUNTIVE, COME ACPI, ecc...
        [*] INDIVIDUARE E SELEZIONARE IL DRIVER CORRETTO

Per individuare velocemente qual'è il driver in uso con il kernel ufficiale puoi usare lspci -k