Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau. -- printk("VFS: Busy inodes after unmount. " "Self-destruct in 5 seconds. Have a nice day...n"); 2.3.99-pre8 /usr/src/linux/fs/super.c
OoO Peu avant le début de l'après-midi du samedi 25 octobre 2003, vers
13:45, "pascal" <pascal.conrad@libertysurf.fr> disait:
Salut,
Avec gcc 3.3.2 et un kernel 2.4.22, lors du modules_install voila un
extrait des erreurs :
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer
les modules compilés avec un gcc 3.3.2. Les modules doivent être
compilés avec le même compilo que le noyau.
--
printk("VFS: Busy inodes after unmount. "
"Self-destruct in 5 seconds. Have a nice day...n");
2.3.99-pre8 /usr/src/linux/fs/super.c
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau. -- printk("VFS: Busy inodes after unmount. " "Self-destruct in 5 seconds. Have a nice day...n"); 2.3.99-pre8 /usr/src/linux/fs/super.c
pascal
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Le make mrproper+make clean doit les virer non ?
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer
les modules compilés avec un gcc 3.3.2. Les modules doivent être
compilés avec le même compilo que le noyau.
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Le make mrproper+make clean doit les virer non ?
pascal
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de fonctionnement ?
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer
les modules compilés avec un gcc 3.3.2. Les modules doivent être
compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de
fonctionnement ?
On Sat, 25 Oct 2003 19:23:08 +0000, Vincent Bernat wrote:
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de fonctionnement ?
J. Mayer
On Sat, 25 Oct 2003 19:23:08 -0700, Vincent Bernat wrote:
OoO Peu avant le début de l'après-midi du samedi 25 octobre 2003, vers 13:45, "pascal" disait:
Salut, Avec gcc 3.3.2 et un kernel 2.4.22, lors du modules_install voila un extrait des erreurs :
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce que une structure change de taille (spinlock_t) si le kernel n'est pas en SMP. Dans le cas présent, le module n'a pas été compilé avec les headers du kernel qui tourne: les get_user sont des macros en assembleur inline....
On Sat, 25 Oct 2003 19:23:08 -0700, Vincent Bernat wrote:
OoO Peu avant le début de l'après-midi du samedi 25 octobre 2003, vers
13:45, "pascal" <pascal.conrad@libertysurf.fr> disait:
Salut,
Avec gcc 3.3.2 et un kernel 2.4.22, lors du modules_install voila un
extrait des erreurs :
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer
les modules compilés avec un gcc 3.3.2. Les modules doivent être
compilés avec le même compilo que le noyau.
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce
que une structure change de taille (spinlock_t) si le kernel n'est
pas en SMP.
Dans le cas présent, le module n'a pas été compilé avec les
headers du kernel qui tourne:
les get_user sont des macros en assembleur inline....
Avant gcc 3.3.2 (2.92) je n'avais aucun probléme !
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce que une structure change de taille (spinlock_t) si le kernel n'est pas en SMP. Dans le cas présent, le module n'a pas été compilé avec les headers du kernel qui tourne: les get_user sont des macros en assembleur inline....
Vincent Bernat
OoO En cette nuit nuageuse du dimanche 26 octobre 2003, vers 01:20, "pascal" disait:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de fonctionnement ?
Non, le depmod fait par make modules_install est bien fait contre le noyau contenu dans les sources. -- BOFH excuse #445: Browser's cookie is corrupted -- someone's been nibbling on it.
OoO En cette nuit nuageuse du dimanche 26 octobre 2003, vers 01:20,
"pascal" <pascal.conrad@libertysurf.fr> disait:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer
les modules compilés avec un gcc 3.3.2. Les modules doivent être
compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de
fonctionnement ?
Non, le depmod fait par make modules_install est bien fait contre le
noyau contenu dans les sources.
--
BOFH excuse #445:
Browser's cookie is corrupted -- someone's been nibbling on it.
OoO En cette nuit nuageuse du dimanche 26 octobre 2003, vers 01:20, "pascal" disait:
Si ton noyau a été compilé avec un 2.95.2, il ne faut pas lui filer les modules compilés avec un gcc 3.3.2. Les modules doivent être compilés avec le même compilo que le noyau.
Ok, il faut rebooter car depmod cherche dans le noyaux en cours de fonctionnement ?
Non, le depmod fait par make modules_install est bien fait contre le noyau contenu dans les sources. -- BOFH excuse #445: Browser's cookie is corrupted -- someone's been nibbling on it.
pascal
"J. Mayer" wrote in news::
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce que une structure change de taille (spinlock_t) si le kernel n'est pas en SMP. Dans le cas présent, le module n'a pas été compilé avec les headers du kernel qui tourne: les get_user sont des macros en assembleur inline....
Ok au reboot, ca marche (angoissant quand on est à 40km de la machine !). Je n'ai qu'un probléme de dépendance sur le hotplug pci compacq. Il doit manquer un truc.
Merci
"J. Mayer" <l_indien_no_more_spams@magic.fr> wrote in
news:pan.2003.10.26.13.00.18.12905@magic.fr:
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce
que une structure change de taille (spinlock_t) si le kernel n'est
pas en SMP.
Dans le cas présent, le module n'a pas été compilé avec les
headers du kernel qui tourne:
les get_user sont des macros en assembleur inline....
Ok au reboot, ca marche (angoissant quand on est à 40km de la machine !).
Je n'ai qu'un probléme de dépendance sur le hotplug pci compacq. Il doit
manquer un truc.
Ca ne génère pas de problèmes de dépendance. Ca crashe, parce que une structure change de taille (spinlock_t) si le kernel n'est pas en SMP. Dans le cas présent, le module n'a pas été compilé avec les headers du kernel qui tourne: les get_user sont des macros en assembleur inline....
Ok au reboot, ca marche (angoissant quand on est à 40km de la machine !). Je n'ai qu'un probléme de dépendance sur le hotplug pci compacq. Il doit manquer un truc.
