Errore durante compilazione kernel

[joe]

Per quanto riguarda rc.modules attualmente col rc.modules-3.3.0 sembra funzionare tutto, l'unica cosa appunto è il driver acpi-cpufreq che và aggiunto decommentandone la riga relativa. Per il momento mi sembrala via più semplice e sono sicuro che funziona per le mie necessità... Eventualmente come dici tu potrei anche fare un backup di quel file rinominandolo in qualche modo per forzare il sistema a seguire rc.modules originario e osservare cosa accade ed eventualmente passare a rc.modules-3.3.0.

Proverò il "make V=1". E vediamo cosa succede...
Sull'opzione -j ci sono pareri discordi, soprattutto con un processore come il mio... che non è propriamente un dual o quad core...
Forse un -j2 snellirebbe i tempi, ma non ho mai misurato la faccenda... provo via...

[joe]

Ho lanciato il tutto come prima redirigendo l'error in un file ad hoc. Così:
root@darkstar:/usr/src/linux# make -j2 V=1 1>/tmp/make-kernel-hand-out.log 2>/tmp/make-kernel-hand-err.log

Ecco le ultime righe del file "err.log":

Codice: Seleziona tutto

drivers/isdn/sc/init.c: In function '__check_irq':
drivers/isdn/sc/init.c:36: warning: return from incompatible pointer type
drivers/isdn/sc/init.c: In function '__check_ram':
drivers/isdn/sc/init.c:37: warning: return from incompatible pointer type
drivers/isdn/sc/init.c: In function 'identify_board':
drivers/isdn/sc/init.c:487: warning: passing argument 1 of 'readl' makes pointer from integer without a cast
/tmp/linux-3.3/arch/x86/include/asm/io.h:55: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
drivers/isdn/sc/init.c:497: warning: passing argument 1 of 'readl' makes pointer from integer without a cast
/tmp/linux-3.3/arch/x86/include/asm/io.h:55: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
drivers/isdn/sc/init.c:507: warning: passing argument 1 of 'readl' makes pointer from integer without a cast
/tmp/linux-3.3/arch/x86/include/asm/io.h:55: note: expected 'const volatile void *' but argument is of type 'long unsigned int'
net/decnet/dn_timer.c:102: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [net/decnet/dn_timer.o] Error 1
make[1]: *** [net/decnet] Error 2
make: *** [net] Error 2
make: *** Waiting for unfinished jobs....
In file included from include/linux/input.h:1137,
                 from include/media/rc-map.h:12,
                 from drivers/media/rc/keymaps/rc-kaiomy.c:13:
include/linux/fs.h:643: error: variably modified 'page_tree' at file scope
make[4]: *** [drivers/media/rc/keymaps/rc-kaiomy.o] Error 1
make[3]: *** [drivers/media/rc/keymaps] Error 2
make[2]: *** [drivers/media/rc] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [drivers/media] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [drivers] Error 2
root@darkstar:~#

Se serve altro non esitate a chiedere.

[shark1500]

Ma va in segmentation fault sempre allo stesso file?
Io fossi in te non aspetterei tanto e manderei un bel reporto ai kernel developers

Codice: Seleziona tutto

Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@redhat.com>
"H. Peter Anvin" <hpa@zytor.com>
x86@kernel.org
Andrew Morton <akpm@linux-foundation.org>
James Bottomley <James.Bottomley@parallels.com>
Roland Dreier <roland@purestorage.com>
Hitoshi Mitake <h.mitake@gmail.com>
linux-kernel@vger.kernel.org

E poi aggiungere anche quelli di GCC (leggi le istruzioni del sito, non conosco come funziona).

[joe]

No, in effetti no...
Nella prima pagina del topic avevo riportato sempre lo standard error del make e andava in panne su questo file:

Codice: Seleziona tutto

drivers/infiniband/core/uverbs_cmd.c:2253: internal compiler error: Segmentation fault

Invece durante l'ultima compilazione come vedi anche sopra:

Codice: Seleziona tutto

net/decnet/dn_timer.c:102: internal compiler error: Segmentation fault

Quindi va in crisi in modo piuttosto random forse...
Sinceramente non ci capisco niente di ste cose.
E mi viene anche da pensare che se alan è riuscito a compilare correttamente il kernel, il problema non stia nei sorgenti del kernel, ma tutt'al più in una combinazione di eventi tipo mia versione di gcc più kernel 3.3.0 ecc ecc.

[414N]

Data la cadenza un po' casuale, che non sia un problema di surriscaldamento del pc che fa "andare in panne" gcc? Mi pare fosse già successo ad un altro utente del forum in passato...
Penso sia facilmente verificabile forzando la frequenza della CPU al valore più basso possibile tramite cpufreq.

[shark1500]

Si`, a questo punto mi viene da pensare anche a me com 414N.
Ho avuto un sacco di brutte esperienze, prova a fare anche un memtest per vedere se la RAM e` a posto.

[joe]

Mmmm proviamo. Il mio processore viene gestito su 4 scalini di frequenza:

Codice: Seleziona tutto

root@darkstar:~# cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1.86 GHz - 3.19 GHz
  available frequency steps: 3.19 GHz, 2.39 GHz, 2.13 GHz, 1.86 GHz
  available cpufreq governors: userspace
  current policy: frequency should be within 1.86 GHz and 3.19 GHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 1.86 GHz.
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1.86 GHz - 3.19 GHz
  available frequency steps: 3.19 GHz, 2.39 GHz, 2.13 GHz, 1.86 GHz
  available cpufreq governors: userspace
  current policy: frequency should be within 1.86 GHz and 3.19 GHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 1.86 GHz.

Ecco, dovrebbe essere tutto al minimo.
Memtest, va dato dal bios oppure si può usare anche a sistema avviato? Non lo trovo tra i comandi della shell, va bè googolo un attimo...

[joe]

Allora ho provato nuovamente a lanciare il "make -j2 V=1". Ho sempre rediretto output ed error su due file distinti.
Sta volta non riscontro errori di segmentation fault... anche se il file di putput non è molto esplicativo nel senso che risulta "mozzato", cioè alla fine non viene scritto "ho creato il kernel, tutto ok ecc.." o qualcosa del genere...

Vi posterei le solite ultime righe dei files di output e di error. Anzi facciamo che li allego in toto così se fosse necessaria un'analisi più approfondita potrete condurla come meglio credete.


Aggiungo una cosa probabilmente banale che potrebbe anche provare il successo dell'ultima compilazione.
Praticamente ho questo file creato proprio in corrispondenza della data di oggi e dell'orario della compilazione.

Codice: Seleziona tutto

root@darkstar:/usr/src/linux# ls -l arch/i386/boot/bzImage
lrwxrwxrwx 1 root root 22 2012-03-30 11:41 arch/i386/boot/bzImage -> ../../x86/boot/bzImage

Quello lì dalla faccia sembra proprio il kernel...
Che sia andato tutto a buon fine sta volta?

E i files di log:

Codice: Seleziona tutto

root@darkstar:/usr/src/linux# ls -l /tmp/make-kernel-hand-*
-rw-r--r-- 1 root root    5607 2012-03-30 11:41 /tmp/make-kernel-hand-err.log
-rw-r--r-- 1 root root 7081656 2012-03-30 11:56 /tmp/make-kernel-hand-out.log

Le date sono le stesse per cui il bzImage è relativo alla compilazione di oggi.

Mi accorgo che il log di output pesa 7MB... un po' troppo per allegarlo qui. Ve ne metto solo le ultime righe.
Allego solo il log error.

Codice: Seleziona tutto

root@darkstar:/usr/src/linux# tail -n 30 /tmp/make-kernel-hand-out.log
  objcopy -Iihex -Obinary firmware/kaweth/trigger_code_fix.bin.ihex firmware/kaweth/trigger_code_fix.bin
  objcopy -Iihex -Obinary firmware/ti_3410.fw.ihex firmware/ti_3410.fw
  objcopy -Iihex -Obinary firmware/ti_5052.fw.ihex firmware/ti_5052.fw
  objcopy -Iihex -Obinary firmware/mts_cdma.fw.ihex firmware/mts_cdma.fw
  objcopy -Iihex -Obinary firmware/mts_edge.fw.ihex firmware/mts_edge.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/edgeport/boot.H16 firmware/edgeport/boot.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/edgeport/boot2.H16 firmware/edgeport/boot2.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/edgeport/down.H16 firmware/edgeport/down.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/edgeport/down2.H16 firmware/edgeport/down2.fw
  objcopy -Iihex -Obinary firmware/edgeport/down3.bin.ihex firmware/edgeport/down3.bin
  /tmp/linux-3.3/firmware/ihex2fw firmware/whiteheat.HEX firmware/whiteheat.fw
  /tmp/linux-3.3/firmware/ihex2fw firmware/keyspan_pda/keyspan_pda.HEX firmware/keyspan_pda/keyspan_pda.fw
  /tmp/linux-3.3/firmware/ihex2fw firmware/keyspan_pda/xircom_pgs.HEX firmware/keyspan_pda/xircom_pgs.fw
  objcopy -Iihex -Obinary firmware/yam/1200.bin.ihex firmware/yam/1200.bin
  objcopy -Iihex -Obinary firmware/yam/9600.bin.ihex firmware/yam/9600.bin
  objcopy -Iihex -Obinary firmware/advansys/mcode.bin.ihex firmware/advansys/mcode.bin
  objcopy -Iihex -Obinary firmware/advansys/38C1600.bin.ihex firmware/advansys/38C1600.bin
  objcopy -Iihex -Obinary firmware/advansys/3550.bin.ihex firmware/advansys/3550.bin
  objcopy -Iihex -Obinary firmware/advansys/38C0800.bin.ihex firmware/advansys/38C0800.bin
  objcopy -Iihex -Obinary firmware/qlogic/1040.bin.ihex firmware/qlogic/1040.bin
  objcopy -Iihex -Obinary firmware/qlogic/1280.bin.ihex firmware/qlogic/1280.bin
  objcopy -Iihex -Obinary firmware/qlogic/12160.bin.ihex firmware/qlogic/12160.bin
  objcopy -Iihex -Obinary firmware/sb16/mulaw_main.csp.ihex firmware/sb16/mulaw_main.csp
  objcopy -Iihex -Obinary firmware/sb16/alaw_main.csp.ihex firmware/sb16/alaw_main.csp
  objcopy -Iihex -Obinary firmware/sb16/ima_adpcm_init.csp.ihex firmware/sb16/ima_adpcm_init.csp
  objcopy -Iihex -Obinary firmware/sb16/ima_adpcm_playback.csp.ihex firmware/sb16/ima_adpcm_playback.csp
  objcopy -Iihex -Obinary firmware/sb16/ima_adpcm_capture.csp.ihex firmware/sb16/ima_adpcm_capture.csp
  /tmp/linux-3.3/firmware/ihex2fw firmware/atmsar11.HEX firmware/atmsar11.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/matrox/g200_warp.H16 firmware/matrox/g200_warp.fw
  /tmp/linux-3.3/firmware/ihex2fw -w firmware/matrox/g400_warp.H16 firmware/matrox/g400_warp.fw

[414N]

Non noto errori nello standard error, percui direi che è andato tutto bene.
Il file immagine che viene creato è proprio arch/x86/boot/bzImage. Tutti gli altri (anche nel caso di x86_64) sono sono link a questo file (ovviamente se rimaniamo in ambito x86 e derivati).
A questo punto direi che devi fare attenzione alla temperatura del tuo sistema. Forse una spolverata alle ventole/feritoie può essere decisiva.

[joe]

Purtroppo mi sa che non basta...
Dico così perchè l'ho pulito non da molto, il pc s'era bloccato completamente, non stava acceso che per pochi minuti giusto il tempo d'avviare il sistema, poi visto che la ventolina non partiva, il surriscaldamento faceva scattare la sicurezza e si spegneva tutto.
Ho poi risolto pulendo l'interno della ventolina dall'esterno con un filo elettrico sottilissimo cercando di uncinare un visibilissimo batuffolo di polvere. Ho poi rifinito con l'aspiratore... quanta pazienza!!!

Dopo quest'operazione la rumorosità è nettamente migliorata, tenendo la frequenza del processore al minimo è diventato piuttosto silenzioso. Solo in caso di lavoro spinto come compilazioni flashplayer ecc la ventolina gira più velocemente.
Ovviamente la silenziosità va persa anche aumentado la frequenza del processore con cpufreq.
Probabilmente c'è di mezzo anche il piccolo radiatore, la pasta termica ecc che sono pur sempre del 2004... Non penso di poter pretendere molto di più...

Inoltre pulire quella cavolo di ventola non è per nulla facile, perchè no si riesce ad accedervi completamente, bisogna lavorare dall'esterno... lavoro lungo noioso e con risultato tutt'altro che perfetto. Infatti verso l'alto si è ostacolati dalla feritoia in palstica che fa parte del case del portatile... vicino alla tastiera per capirci.
Aprendo il portatile sul retro, si trova un radiatore in rame che non permette l'accesso diretto alla ventolina. Dal radiatore si dipartono due tubicini sempre in rame che arrivano alla cpu. Sembra tutto un blocco, pertanto non ho forzato lo smontaggio, anche perchè non sono esperto e non vorrei trovarmi con qualcosa di non funzionante del tutto...

Bè, basta sapere che per compilare occorre tenere la frequenza al minimo. Certo non è il massimo della vita.... anche perchè così non si sfrutta appieno il processore. Pazienza.

[shark1500]

Memtest e` un programma che si avvia da CD (ad esempio c'e` nel cd di ubuntu). Praticamente riavvii il computer con il CD dentro e fai partire memtest, il quale ti scanna tutta la RAM per vedere se ci sono dei problemi.

Prova a farlo e guarda se trova qualcosa. NOTA: Ci mette un po` di tempo.

[joe]

È presente nel cd di slackware?
Comunque ho visto che si può mettere anche l'eseguibile in /boot e poi creare una nuova entry in lilo.conf, all'avvio dovrebbe far scegliere l'esecuzione di memtest accanto ai kernel installati.
Riporto quanto ho letto:

Load by LILO
1. Extract memtest86+ archive to /boot :
$ cd /boot
$ sudo gzip -d memtest86+-1.70.bin.gz
$ sudo mv memtest86+-1.70.bin mt86p.bin
2. Edit /etc/lilo.conf add follow entry :
### LILO memory test section (memtest)
image = /boot/mt86p.bin
label = memtest86+

then run:
$ sudo /sbin/lilo

Fonte: http://ayinat.blogspot.it/2007/07/test- ... -load.html

Mi sembra più semplice senza tirare in ballo CD usb key ecc ecc...

[shark1500]

Prova, io non ho mai provato. Ho sempre fatto un dd al volo quelle volte che mi serviva.

[conraid]

È presente nel cd di slackware?

Guarda, io non ho mai provato, ma durante il boot con il CD/DVD di installazione si può leggere

To test your memory with memtest86+, enter memtest on the boot line below.

Quindi immagino che ci sia

[joe]

Ho seguito le indicazioni che avevo riportato sopra installando il binario di memtest in /boot, poi ho modificato lilo.conf eggiornato e riavviando c'è la nuova voce. L'altro giorno poi avevo provato a far girare memtest, ma è lunghissimo... dopo due ore che macinava ho deciso che poteva bastare e visto che mi serviva il computer, ho interrrotto tutto...