Newsgroup: it.comp.os.linux.iniziare
Titolo: Un'anomalia (risolta) sul modulo emu10k1.o: cosa ne pensate?

Mi presento: sono Giuseppe. E' da quasi un anno che osservo questo NG, e
devo dire che grazie a voi ho imparato tantissimo.
Ho sempre fatto quasi tutto da solo, tranne per i preziosi aiuti che
molte volte ho avuto da Vanni Brutto, che mi ha iniziato alla filosofia
di Linux (e per questo lo ringrazio...ciao Vanni! :-)).
Bene. Adesso mando questo post perché è sorto un problema (già risolto,
per fortuna), sulle cui cause sono però rimasto alquanto perplesso.
Dunque...ho una RH 6.1 con parecchi pacchetti della 6.2.
E' da tempo ormai che aggiorno i drivers della SBLive! dal sito
opensource della Creative, e fino a qualche settimana fa tutto andava
bene.
In questi giorni è accaduta una cosa: ho cercato di aggiornare per
l'ennesima volta i drivers, ma stavolta niente...ho ottenuto i seguenti
messaggi di errore:
[root@localhost peppe]# depmod -a
/lib/modules/2.2.17/misc/emu10k1.o: unresolved symbol(s)
[root@localhost peppe]# modprobe emu10k1
/lib/modules/2.2.17/misc/emu10k1.o: unresolved symbol ac97_probe_codec
qui ho intuito che mancava qualcosa....dal momento che ho sempre
installato i moduli senza fare "make install", bensì copiando il modulo
emu10k1.o manualmente, non mi ero accorto che stavolta andava installato
anche un altro modulo: ac97_codec.o (me ne sono accorto guardando il
Makefile).
Bene. Notato ciò, ho dato un bel "modprobe ac97_codec" e poi:
[root@localhost peppe]# modprobe emu10k1
/lib/modules/2.2.17/misc/emu10k1.o: init_module: Dispositivo o risorsa
occupata
[root@localhost peppe]# modprobe emu10k1-joy
/lib/modules/2.2.17/misc/emu10k1-joy.o: init_module: Dispositivo o
risorsa occupata
Una cosa strana: ho provato a "tornare indietro" ricompilando l'ultima
versione del driver che da me ha sempre funzionato a dovere, e ho
ottenuto (al momento di installarlo) di nuovo il messaggio:
root@localhost peppe]# modprobe emu10k1
/lib/modules/2.2.17/misc/emu10k1.o: init_module: Dispositivo o risorsa
occupata
Rimettendo però il binario (che fortunatamente avevo messo da parte) che
in passato ha funzionato, il modprobe ha funzionato a dovere e la SBLive!
ha "suonato".
Ho notato anche che i due moduli della stessa versione, una volta
compilati, sono (neanche a dirlo) diversi anche per dimensione.
Dopo un pomeriggio di tentativi, ho finalmente scoperto cosa è successo.
Ultimamente ho ricompilato il kernel per un mio vecchio 486 DX2/80, e
l'ho fatto sul mio Celeron 300A.
Bene, con la compilazione viene modificato il file
/usr/src/linux/.config in base alle esigenze del 486.
Ho notato che il Makefile dei drivers della Live! importa proprio questo
config, e da qui il danno.
Facendo infatti la prova a riportare il .config ai parametri per il
Celeron, la compilazione del modulo emu10k1.o ha portato a un binario
diverso da quello non funzionante. Quest'ultimo emu10k1.o invece (per
fortuna) ha funzionato.
Quindi qualcosa è andato storto nel link con le librerie di sistema
(suppongo, ma sono un profano), ma non capisco cosa.
Qualcuno ha qualche idea?
Certo che è strano....questi moduli, quando vengono compilati, non
dovrebbero essere in qualche modo indipendenti dal processore,
specialmente se il salto è verso l'alto (486 vs. celeron)?
Grazie.
-- 
Ciao,
Giuseppe.
---
Togliete "nessuno" per rispondere via e-mail
---

di Linux (e per questo lo ringrazio...ciao Vanni! :-)).
Più che preziosi consigli sono state  solo quattro dritte, cmq dal canto
mio ti do il mio benvenuto su questo ng :-)
Per il problema  del modulo emu10k1 'fettivamente  è piuttosto strano...
anch'io così su due piedi penserei che i moduli audio non hanno niente a
che  vedere con  il processore  per  il quale  vengono compilati,  anche
perché  come  avevi  giustamente  detto un  modulo  compilato  per  i486
dovrebbe girare perfettamente  anche su di un PIII  (ovviamente non vale
il viceversa).
Purtroppo credo  che si potrebbe  trovare la risposta solo  spulciando i
sorgenti del modulo, cosa al di fuori della mia portata.
byeZ!
-- 
Vanni Brutto                                      .--.
| email 
za...@nofesso.linuxfan.com
   |           |o_o |
| irc nick VanniB   |   ICQ 18526701 |           |:_/ |
--- rimuovi nofesso per rispondere ---          //   \ \
--------------------------------------         (|     | )
Gesu':   "y=ax2+bx+c".  I   discepoli:        /'\_   _/`\
"Uffa, un'altra parabola!".                   \___)=(___/

specialmente se il salto č verso l'alto (486 vs. celeron)?
No. Un modulo e' semplicemente una specie di libreria che viene richiamata
dal kernel a runtime, ma il processo di compilazione e' lo stesso utilizzato
da qualunque altro sorgente; quindi se compili per K7 o per 486, il codice
puo' prevedere ottimizzazioni per l'uno o per l'altro caso, senza tenere
conto del fatto che il compilatore stesso puo' generare codice diverso a
seconda del processore per cui si sta compilando - sempre all'interno della
stessa architettura, ovvio.
Ciao.
-- 
 * GOD is real, unless declared as integer *
 * Stefano Rivoir   -   s.rivoir at 
gts.it
 *


Infatti, era per questo che ero stupito: mi domandavo come mai,
cambiando i settaggi del .config del kernel, in un caso il modulo ha
funzionato e nell'altro no.
Ho sempre creduto che tutto questo non avrebbe influito sul corretto
funzionamento del modulo, in quanto anche quando si fa una installazione
da zero (RH 6.2 ecc.), i moduli inseriti sono quelli compilati (se non
sbaglio) per un uso a partire dai processori di classe inferiore, quindi
si adatterebbe anche al mio caso.
E' per questo che non ci capisco piů niente! ;-))
Ciao,
Giuseppe.



Sei sempre modesto.....comunque grazie del "benvenuto"!
