Probléme de modules.... Ca m'agace de plus en plus ....
21 réponses
pascal
Salut,
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se
charge plus, sauf si je les met dans /etc/modules.autoload.d/. En
particulier aic7xxx et forcedeth.
Et Depuis hier, suite au freeze lors d'une visionnage d'un streaming real
(il aime pas Jules Edouard Moustic...), les pilotes de la carte son (alsa)
ne se charge plus, le pilote NVIDIA non plus (d'ailleurs, il m'indique
toujours un kernel 2.4.25-gentoo-r2 !!!!!)
Mais bonne nouvelle, le modem USB ADSL fontionne !!!!!................
Passer sous Win$, ca me fait franchement ch.er ! Mais là, je commence à
faiblir.....
ben ... si tu charge les modules ils occuperont la meme place quand meme ... si tu compile uniquement les modules dont tu as besoin, en dur, ca prendra certes de la place mais une place qui sera quand meme prise si tu les charges apres ...
C'est vrai. D'un autre côté, dans le cas d'ALSA, c'est déconseillé de le compiler en dur.
Rakotomandimby Mihamina wrote in message
<pan.2004.10.06.05.54.12.890885@mail.rktmb.org>:
ben ... si tu charge les modules ils occuperont la meme place quand meme
... si tu compile uniquement les modules dont tu as besoin, en dur, ca
prendra certes de la place mais une place qui sera quand meme prise si tu
les charges apres ...
C'est vrai. D'un autre côté, dans le cas d'ALSA, c'est déconseillé de le
compiler en dur.
ben ... si tu charge les modules ils occuperont la meme place quand meme ... si tu compile uniquement les modules dont tu as besoin, en dur, ca prendra certes de la place mais une place qui sera quand meme prise si tu les charges apres ...
C'est vrai. D'un autre côté, dans le cas d'ALSA, c'est déconseillé de le compiler en dur.
pascal
On Wed, 06 Oct 2004 11:51:03 +0200, TiChou wrote:
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se charge plus, sauf si je les met dans /etc/modules.autoload.d/. [...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin complet.
depmod -a ?
Pas de réponse ? Tant pis.
Pas eu la précédente (d'ailleurs, c'est pas la première fois....).
man depmod ne me dit rien sur -a. Il ne retourne pas d'info. Il est à noter que je n'utilise pas genkernel.
On Wed, 06 Oct 2004 11:51:03 +0200, TiChou wrote:
Dans le message <news:gniii.20041005233933@florizarre.tichou.org>,
*TiChou* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se
charge plus, sauf si je les met dans /etc/modules.autoload.d/.
[...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin
complet.
depmod -a ?
Pas de réponse ? Tant pis.
Pas eu la précédente (d'ailleurs, c'est pas la première fois....).
man depmod ne me dit rien sur -a.
Il ne retourne pas d'info.
Il est à noter que je n'utilise pas genkernel.
Dans le message <news:, *TiChou* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se charge plus, sauf si je les met dans /etc/modules.autoload.d/. [...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin complet.
depmod -a ?
Pas de réponse ? Tant pis.
Pas eu la précédente (d'ailleurs, c'est pas la première fois....).
man depmod ne me dit rien sur -a. Il ne retourne pas d'info. Il est à noter que je n'utilise pas genkernel.
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se charge plus, sauf si je les met dans /etc/modules.autoload.d/. [...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin complet.
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne plus d'informations sur les options disponibles. Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur une piste. Après chaque compilation et installation d'un nouveau noyau et de ses modules on doit mettre à jour la liste des dépendances des modules avec la commande 'depmod -a'. Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod' plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il serait préférable d'utiliser cet outil qui facilite bien les choses en automatisant au maximum l'installation d'un nouveau noyau.
-- TiChou
Dans le message <news:pan.2004.10.06.16.13.22.54864@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se
charge plus, sauf si je les met dans /etc/modules.autoload.d/.
[...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin
complet.
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne
plus d'informations sur les options disponibles.
Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur
une piste.
Après chaque compilation et installation d'un nouveau noyau et de ses
modules on doit mettre à jour la liste des dépendances des modules avec la
commande 'depmod -a'.
Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que
soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des
dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est
pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la
commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod'
plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation
d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il
serait préférable d'utiliser cet outil qui facilite bien les choses en
automatisant au maximum l'installation d'un nouveau noyau.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Suite au passage de ma gentoo sur un kernel 2.6.8.1, les modules ne se charge plus, sauf si je les met dans /etc/modules.autoload.d/. [...]
En gros, insmod ne marche pas si on lui spécifie pas le chemin complet.
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne plus d'informations sur les options disponibles. Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur une piste. Après chaque compilation et installation d'un nouveau noyau et de ses modules on doit mettre à jour la liste des dépendances des modules avec la commande 'depmod -a'. Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod' plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il serait préférable d'utiliser cet outil qui facilite bien les choses en automatisant au maximum l'installation d'un nouveau noyau.
-- TiChou
pascal
On Wed, 06 Oct 2004 18:43:06 +0200, TiChou wrote:
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne plus d'informations sur les options disponibles. Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur une piste. Après chaque compilation et installation d'un nouveau noyau et de ses modules on doit mettre à jour la liste des dépendances des modules avec la commande 'depmod -a'. Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod' plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il serait préférable d'utiliser cet outil qui facilite bien les choses en automatisant au maximum l'installation d'un nouveau noyau.
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules. Je me suis rendu compte que /usr/include/linux était statique. Je l'ai mis en lien sur /usr/src/linux/include/linux. A voir avec le pilote NVIDIA Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
On Wed, 06 Oct 2004 18:43:06 +0200, TiChou wrote:
Dans le message <news:pan.2004.10.06.16.13.22.54864@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne
plus d'informations sur les options disponibles.
Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur
une piste.
Après chaque compilation et installation d'un nouveau noyau et de ses
modules on doit mettre à jour la liste des dépendances des modules avec la
commande 'depmod -a'.
Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que
soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des
dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est
pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la
commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod'
plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation
d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il
serait préférable d'utiliser cet outil qui facilite bien les choses en
automatisant au maximum l'installation d'un nouveau noyau.
Je compile des kernel depuis 96. J'ai de mauvaises habitudes.
Le fichier /lib/modules/2.6.8.1/modules.dep est correcte.
Normalement, un 'depmod -qa' est générer après installation des modules.
Je me suis rendu compte que /usr/include/linux était statique. Je l'ai
mis en lien sur /usr/src/linux/include/linux. A voir avec le pilote NVIDIA
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec
'[modules] needs [function]'. C'est normal ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de
probléme avec le 2.4.27...
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
depmod -a ?
man depmod ne me dit rien sur -a.
Effectivement, le manuel semble incomplet. La commande 'depmod --help' donne plus d'informations sur les options disponibles. Il n'empêche que le manuel de la commande 'depmod' aurait du vous mettre sur une piste. Après chaque compilation et installation d'un nouveau noyau et de ses modules on doit mettre à jour la liste des dépendances des modules avec la commande 'depmod -a'. Si la commande 'insmod' ne trouve pas de lui même les modules, c'est que soit ils n'ont pas été installé (voir compilé...) ou que soit la liste des dépendances des modules (fichier /lib/modules/`uname -r/modules.dep) n'est pas à jour.
Il ne retourne pas d'info.
Qui ne retourne pas d'information, le manuel ou la commande ? Si c'est la commande, alors c'est plutôt bon signe. Pour rendre la commande 'depmod' plus bavarde, rajoutez l'option verbose '-v'.
Il est à noter que je n'utilise pas genkernel.
Si vous savez exactement ce que vous faites et êtes habitué à l'installation d'un nouveau noyau et de ses modules, pourquoi pas. Sinon, peut-être qu'il serait préférable d'utiliser cet outil qui facilite bien les choses en automatisant au maximum l'installation d'un nouveau noyau.
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules. Je me suis rendu compte que /usr/include/linux était statique. Je l'ai mis en lien sur /usr/src/linux/include/linux. A voir avec le pilote NVIDIA Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout ça ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
Ce modem ne fonctionne pas avec un noyau 2.4.x ?
-- TiChou
Dans le message <news:pan.2004.10.06.19.00.39.392331@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes.
Le fichier /lib/modules/2.6.8.1/modules.dep est correcte.
Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir
ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le
compilateur a été compilé.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec
'[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout
ça ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de
probléme avec le 2.4.27...
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout ça ?
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
Ce modem ne fonctionne pas avec un noyau 2.4.x ?
-- TiChou
Sebastien Kirche
Le 6 Oct 2004, TiChou s'est exprimé ainsi :
Salut Tichou,
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé. ^^^^^^^^^^^^^^
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Séki
Le 6 Oct 2004, TiChou s'est exprimé ainsi :
Salut Tichou,
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels
le compilateur a été compilé.
^^^^^^^^^^^^^^
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé. ^^^^^^^^^^^^^^
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Séki
Nicolas George
Sebastien Kirche wrote in message :
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la même chose. L'idée, c'est que le compilateur et la libc ont une certaine vue des structures et types du système (taille des entiers, structures du noyau), etc.), et qu'il faut que cette vue soit transmise de manière cohérente aux programmes compilés.
En particulier, la glibc traduit à la volée toutes les structures de données passées par le/au noyau pour unifier la taille des champs, et assurer à l'avenir une compatibilité binaire complète. C'est un peu coûteux.
Sebastien Kirche wrote in message <m2zn2ysxwk.fsf@seki.fr>:
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la
même chose. L'idée, c'est que le compilateur et la libc ont une certaine vue
des structures et types du système (taille des entiers, structures du
noyau), etc.), et qu'il faut que cette vue soit transmise de manière
cohérente aux programmes compilés.
En particulier, la glibc traduit à la volée toutes les structures de données
passées par le/au noyau pour unifier la taille des champs, et assurer à
l'avenir une compatibilité binaire complète. C'est un peu coûteux.
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la même chose. L'idée, c'est que le compilateur et la libc ont une certaine vue des structures et types du système (taille des entiers, structures du noyau), etc.), et qu'il faut que cette vue soit transmise de manière cohérente aux programmes compilés.
En particulier, la glibc traduit à la volée toutes les structures de données passées par le/au noyau pour unifier la taille des champs, et assurer à l'avenir une compatibilité binaire complète. C'est un peu coûteux.
Sebastien Kirche
Le 7 Oct 2004, Nicolas George vraute :
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la même chose. L'idée, c'est que le compilateur et la libc ont une certaine vue des structures et types du système (taille des entiers, structures du noyau), etc.), et qu'il faut que cette vue soit transmise de manière cohérente aux programmes compilés.
Ok, je confond /usr/include et /usr/src/linux en fait.
Séki
Le 7 Oct 2004, Nicolas George vraute :
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la
même chose. L'idée, c'est que le compilateur et la libc ont une certaine
vue des structures et types du système (taille des entiers, structures du
noyau), etc.), et qu'il faut que cette vue soit transmise de manière
cohérente aux programmes compilés.
Ok, je confond /usr/include et /usr/src/linux en fait.
Je suis distraitement, mais il ne faut pas lire «noyau» là ?
Non, le compilateur, ou éventuellement la libc, mais c'est censé être la même chose. L'idée, c'est que le compilateur et la libc ont une certaine vue des structures et types du système (taille des entiers, structures du noyau), etc.), et qu'il faut que cette vue soit transmise de manière cohérente aux programmes compilés.
Ok, je confond /usr/include et /usr/src/linux en fait.
Séki
pascal
On Wed, 06 Oct 2004 21:52:23 +0200, TiChou wrote:
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je vais tester.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne correspondait pas au noyaux. A la base, sur les premières distrib, c'était comme ça.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout ça ?
Oui.
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
Ce modem ne fonctionne pas avec un noyau 2.4.x ? Non, des problémes avec l'ATM provoquait des déconnection lors de fortes
charges, sur des problémes mémoires.
On Wed, 06 Oct 2004 21:52:23 +0200, TiChou wrote:
Dans le message <news:pan.2004.10.06.19.00.39.392331@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes.
Le fichier /lib/modules/2.6.8.1/modules.dep est correcte.
Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir
ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je vais tester.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le
compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne
correspondait pas au noyaux.
A la base, sur les premières distrib, c'était comme ça.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec
'[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout
ça ?
Oui.
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de
probléme avec le 2.4.27...
Ce modem ne fonctionne pas avec un noyau 2.4.x ?
Non, des problémes avec l'ATM provoquait des déconnection lors de fortes
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je compile des kernel depuis 96. J'ai de mauvaises habitudes. Le fichier /lib/modules/2.6.8.1/modules.dep est correcte. Normalement, un 'depmod -qa' est générer après installation des modules.
Exact, je me suis emballé... La commande 'depmod -a' est à faire après avoir ajouté des modules ne provenant pas du noyau, par exemple le module nVidia.
Je vais tester.
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne correspondait pas au noyaux. A la base, sur les premières distrib, c'était comme ça.
A voir avec le pilote NVIDIA
Ça n'a aucune incidence.
Avec depmod -va, j'ai constaté un nombre de dépendance en 'erreurs' avec '[modules] needs [function]'. C'est normal ?
Non. Les sources de votre noyau sont-elles propres ? make mrproper et tout ça ?
Oui.
Et tout ça pour faire marcher mon modem Olitec...... Je n'avais pas de probléme avec le 2.4.27...
Ce modem ne fonctionne pas avec un noyau 2.4.x ? Non, des problémes avec l'ATM provoquait des déconnection lors de fortes
charges, sur des problémes mémoires.
TiChou
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne correspondait pas au noyaux.
Il n'y a pas besoin que les en-têtes soient de la même version que le noyau. Nicolas George a su bien mieux que moi expliqué pourquoi. Si une application grince parce que la version des en-têtes est différente de la version du noyau, c'est qu'elle est très mal codée... il n'y a aucune raison qu'elle grince.
A la base, sur les premières distrib, c'était comme ça.
C'est vrai et pour des raisons bien particulières qui ne sont plus valables depuis bien longtemps. Les distributions faisaient encore il n'y a pas si longtemps ça un peu n'importe quoi mais comme la plupart sont devenues plus ou moins « intelligentes », elles ne font alors plus la même erreur.
Et puis rendons à César ce qui est à César :
http://groups.google.fr/groups?selmú
-- TiChou
Dans le message <news:pan.2004.10.07.18.26.12.294851@libertysurf.fr>,
*pascal* tapota sur f.c.o.l.configuration :
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels
le compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne
correspondait pas au noyaux.
Il n'y a pas besoin que les en-têtes soient de la même version que le noyau.
Nicolas George a su bien mieux que moi expliqué pourquoi.
Si une application grince parce que la version des en-têtes est différente
de la version du noyau, c'est qu'elle est très mal codée... il n'y a aucune
raison qu'elle grince.
A la base, sur les premières distrib, c'était comme ça.
C'est vrai et pour des raisons bien particulières qui ne sont plus valables
depuis bien longtemps. Les distributions faisaient encore il n'y a pas si
longtemps ça un peu n'importe quoi mais comme la plupart sont devenues plus
ou moins « intelligentes », elles ne font alors plus la même erreur.
Dans le message <news:, *pascal* tapota sur f.c.o.l.configuration :
Je me suis rendu compte que /usr/include/linux était statique.
C'est une très bonne chose.
Je l'ai mis en lien sur /usr/src/linux/include/linux.
C'est une très mauvaise chose. Il faut garder les en-têtes avec lesquels le compilateur a été compilé.
J'avais déjà rencontrés des problémes sur des applis car les entêtes ne correspondait pas au noyaux.
Il n'y a pas besoin que les en-têtes soient de la même version que le noyau. Nicolas George a su bien mieux que moi expliqué pourquoi. Si une application grince parce que la version des en-têtes est différente de la version du noyau, c'est qu'elle est très mal codée... il n'y a aucune raison qu'elle grince.
A la base, sur les premières distrib, c'était comme ça.
C'est vrai et pour des raisons bien particulières qui ne sont plus valables depuis bien longtemps. Les distributions faisaient encore il n'y a pas si longtemps ça un peu n'importe quoi mais comme la plupart sont devenues plus ou moins « intelligentes », elles ne font alors plus la même erreur.
