Newsgroup: it.comp.os.linux.sys
Titolo: una cosa strana con System.map

System.map-kernel version e poi /proc/qualcosa ???
Succede la stessa cosa anche a me (sempre Debian 3.0r1, kernel 2.4.22-ac4).
Tu hai risolto?
Alessandro.

 Tu hai risolto?
Miiii... e' passato parecchio tempo ed ora non ricordo piu' come ho
risolto...
Bho.. cmq il kernel lo hai compilato sulla stessa macchina, o su una
diversa?
Se lo hai compilato su una diversa, sei sicuro che il gcc di entrambe le
macchine si la stessa versione?
Se mi viene in mente come ho risolto te lo dico.
CYA
Banana


Grazie. Non e' urgante (fortunatamente mi da' problemi solo con moduli
"secondari") ma e' alquanto inquietante.
Alessandro.

 "secondari") ma e' alquanto inquietante.
Gia'.
Cmq sia, prova a controllare che la ram non si sia guastata, scarica la
iso bootabile di memtest86 v3.0 dal sito 
www.memtest86.com
, (solo 1.6
Mb). Se hai un'altra macchina con debian e la stessa versione di gcc
prova a compilarlo su quella. Fai il make dep clean bzImage modules su
una macchina e il make modules_install sulla macchina incriminata.
Ma prima di fare le cose indicate sopra, rispondi alle seguenti domande:
Hai fatto piu' di una compilazione dagli stessi sorgenti?
Hai lanciato make clean?
Hai cambiato extraversion ad ogni ricompilazione?
cya
Banana


Questo non l'ho fatto. E' importante?
Comunque nel dubbio ho rimosso completamente /lib/modules/versionekernel.
Alessandro.
P.S. Il kernel lo ricompilo a mano, senza usare dpkg.



> Comunque nel dubbio ho rimosso completamente /lib/modules/versionekernel.
Sono du e 'procedure' diverse per ottenere lo stesso risultato, che e'
quello di non mischiare i moduli vecchi con quelli nuovi.
Io preferisco editare il makefile e modificare l'extraversion.
Ti faccio un esempio.
Mi compilo il kernel 2.8.254 per il mio eniac, il primo che creo lo
chiamero' 2.8.254-eniac-1.0.
Poi mi accorgo che:
- Non ho compilato il modulo per il tostapane laser di guerre stallari 
  collegato via porta parallela.
- Ho compilato per sbaglio il driver della stiracapelli ibm
  SWSXSA-Series, che non mi serve.
- Non ho incluso statisticamente nel kernel il supporto per il
  filesystem del nastro setreo 8 di mio cugggino, nel quale ho
  memorizzato in mp3 l'omonimo successo di elio e le storie tese.
Allora compilo la seconda versione e la chiamo 2.8.254-eniac-1.1,
modificando l'extraversion da 1.0 a 1.1.
Ottengo un nuovo kernel e nuovi moduli che non fanno casino con il
kernel compilato precedentemente, ed il kernel 2.8.254-eniac-1.0 resta
li ancora funzionante.
Banana


Fatto ma il risultato non cambia :-(
A questo punto mi viene il dubbio sul kernel: c'e qualcuno che usa il kernel 
2.4.22-ac4 su debian woody ed iptables abilitato?
Alessandro.


Non credo sia un problema di kernel, a me succedeva con il 2.4.18, a te
con il 2.4.22. C'era qualcun altro che prima di me aveva avuto gli
stessi problemi sempre su un 2.4.18 che mi ha contattato, ed aveva
sempre una debian. Ma ora non ricordo chi era. 
Prova magari a chiedere su debian-italian, probabilmente ne sanno di piu'
Cmq anche il mio kernel ha iptables abilitato, pezzi built-in ed altri
come moduli.
Cmq il kernel che mi dava problemi ad un tratto si e' sistemato, e sta
ancora girando su quella macchina. Non ricordo prorpio cosa ho fatto per
sistemarlo.
Banana

 CPU con hyperthreading[=fregatura]
Il fatto stesso che esista una tale tecnologia indica la scarsa qualità
progettuale del Pentium 4, talmente inefficiente su un singolo thread che
mediamente metà della pipeline e delle unità di calcolo passano il loro
tempo a girarsi i pollici.
Hyperthreading però (come i millemila GHz del P4) fanno molto figo in bocca
ai commerciali e presunti informatici e purtroppo ci troviamo questo aborto
rifilato ovunque...
Proprio la settimana scorsa mi sono imbattuto nell'ennesimo commerciante che
voleva rifilarmi un P4 al posto dell'Athlon che gli avevo chiesto adducendo
scuse allucinanti del tipo "Funzionano male e sono inaffidabili... sono
fragili e rischiano di fondere in ogni momento..." ... e il problema e che
molta gente crede a queste fesserie...
Addirittura secondo questo qua i Duron funzionano "male", "non fanno sempre
il loro lavoro"... sì... al massimo 8 ore al giorno con 1 ora di pausa
pranzo, altrimenti scioperano per una settimana incatenandosi al case!
-- 
"It is not enough to succeed.  Others must fail."
Linux Registered User #301571, running Gentoo
Memeber of Luganega - Linux User Group Crema (IT)
http://filibusta.crema.unimi.it/

 chiamero' 2.8.254-eniac-1.0.
La tua disponibilità di HW e di kernel è legata in qualche modo allo
spacciatore di cui sopra? Perchè se è così, passalo a me, dato che tu lo
cambi...
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Skull says:
Stop VeriSign. Go to 
http://www.whois.sc/verisign-dns/
* The most stupid thing since Microsoft Network... <g> *

 progettuale del Pentium 4,
Premetto che non sono un esperto di CPU (quindi non me la sento di
confermare un affermazione cosi' forte). Dico solo che non ho avuto modo di
apprezzarne i benefici.
Per esempio:
cd /usr/src/linux
make clean
time make bzImage # compilazione sequenziale
real    2m2.804s
user    1m51.400s
sys     0m6.640s
make clean
time make -j2 bzImage # il lavoro viene distribuito su 2 processi paralleli
real    1m38.143s
user    3m4.440s
sys     0m9.190s
make clean
time make bzImage # compilazione sequenziale
real    1m57.032s
user    1m52.340s
sys     0m8.500s
make clean
time make -j2 bzImage # il lavoro viene distribuito su 2 processi paralleli
real    1m38.013s
user    3m4.120s
sys     0m9.890s
Legenda:
real=tempo effettivamente trascorso
user=tempo cpu consumato in user space
user=tempo cpu consumato dal sistema
Scartando la prima misurazione (le successive beneficiano della presenza dei
dati in cache) si vede che il beneficio dell'esecuzione parallela non e'
eccezionale (il tempo effettivo e' simile ed il tempo CPU consumato
raddoppia) e mi viene il dubbio che su un sistema monoprocessore
tradizionale si avrebbero risultati analoghi.
Per la verita' Intel stessa promette un miglioramento delle prestazioni solo
fino al 25% ma il fatto di avere due processori "logici" avrebbe fatto
sperare in qualcosina di piu'. Di fatto questo illude anche il sistema
operativo ed ho letto di un patch allo scheduler di Linux per far si' che,
avendo sullo stesso sistema piu' cpu con hyperthreading, venga scelto per
l'esecuzione, se possibile, un processore logico su una cpu libera piuttosto
che su una gia' occupata.
Followup impostato.
Alessandro