N'est pas d'accord à propos de la version de symbole symbol_name après insmod

Je suis nouveau dans la programmation du noyau.

Pour la mise en œuvre de mon projet, j'ai téléchargé la dernière version stable de noyau (v4.3) de kernel.org.

Juste pour vérifier que j'ai copié quelques fichiers à partir du noyau des répertoires dans mon répertoire de projet. Apporté des modifications à elle et inséré un peu plus de code.

Puis j'ai compilé sur SLES11 noyau Linux à l'aide de

make -C /lib/modules/$(uname -r)/build M=$PWD modules

J'ai utilisé le makefile ci-dessous

obj-m := my_module.o
my_module-objs := module_main.0 other_module1.o other_module2.o other_module3.o

Il compilé avec succès.
Mais quand j'ai essayé de l'insérer dans le noyau à l'aide de 

insmod my_sample.ko

Il a démontré ce qui suit

n'est pas d'accord à propos de la version de symbole symbol_name

N'est pas d'accord à propos de la version de symbole symbol_name après insmod

InformationsquelleAutor user3243499 | 2015-11-16
  1. 2

    Le problème ici est que le Noyau du module en utilisant les symboles exportés d'autres modules du noyau qui, dans ce cas semble être le linux InfiniBand RDMA pile exporté des méthodes ou des symboles.

    Pour résoudre le symbole des problèmes de la version, copiez le Module.symvers fichier à partir de la 

    /usr/src/ofa-kernel

    répertoire et le coller dans votre répertoire de travail courant. Ensuite, vous faites vos modules de nouveau. Maintenant, le insmod devrait fonctionner parfaitement bien.

    REMARQUE: Le Module.symvers fichier contient des informations de tout le noyau
    module de symboles exportés. Donc, en le copiant dans votre répertoire de travail,
    vous aider kbuild pour en savoir plus sur l'utilisation les symboles exportés.

    Et si vous ne trouvez pas le Module.symvers ou il est vide, puis en créer un à l'aide de create_Module.symvers.sh

    • Passé des heures à essayer de résoudre ce problème. Il fonctionne!
    • J'ai le même problème sur ubuntu 14.04. La copie à partir de /usr/src/de-kernel/par défaut, na pas résoudre le problème. /usr/src/oof-noyau n'a qu'un seul répertoire par défaut. Installé le pilote via mlnx-ofed-noyau 3.3 qui créé de l'oof-noyau et de l'oof-kernel-3.3. S'il vous plaît aider. Merci.
    InformationsquelleAutor Utkal Sinha
  2. 8

    Vous avez besoin pour construire votre module de noyau avec la même version du noyau que vous allez exécuter. Donc si vous avez noyau 4.3 sources que vous avez téléchargé, vous devez compiler que version du noyau et de démarrage avec celle en cours d'exécution avant d'essayer de charger votre noyau.

    Vous avez deux solutions alors:

    1. Télécharger les sources du noyau pour le noyau que vous utilisez actuellement (vous pouvez les installer avec zypper install kernel-source sur SLES ou une commande équivalente sur les autres distributions.)
    2. Compiler et installer la 4.3 noyau de votre système d'exploitation. Si vous avez besoin d'aide alors poser une autre question (et il appartient probablement sur superuser pas ici). Notez que si le noyau et la glibc sont étroitement couplés, et il est possible que vous ne pouvez pas exécuter un nouveau noyau si vous avez une très vieille bibliothèque C.
    • J'ai téléchargé la src fichiers de /usr/src/ répertoire dans le noyau en cours d'exécution. Puis faire la même édition. Nouveau compilé correctement, mais lorsque j'essaie de insmod l' .ko fichier, il affiche les mêmes problèmes de version, comme indiqué ci-dessus instantané. La version du noyau ( uname -r montre 3.0.76-0.11-par défaut ) et insmod -V montre ( module-init-tools version 3.11.1 ) s'il vous plaît aider.
    • Également en cours d'exécution cat /proc/version c'est montrer Linux Version 3.0.76-0.11-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)) . Alors, quelle version dois-je utiliser ?
    • Si vous voulez que votre module pour s'exécuter sous le noyau que vous utilisez actuellement, vous aurez besoin de le compiler à l'encontre d'un noyau (3.0). Vous devriez être en mesure d'obtenir le noyau d'origine sources pour construire à partir de SuSE.
    • vous avez besoin de compiler avec la même version du noyau que vous souhaitez charger le module contre. Vous avez un noyau en version 3.0 et d'un module de la version 3.11. Si vous n'avez pas les sources de votre noyau. Je ne suis pas familier avec SLES donc je ne suis pas sûr de savoir où obtenir les bonnes sources de.
    • J'ai juste cherché Suse liste de paquet pour leurs paquets et le noyau par défaut est la version 2.6.27.19 (suse.com/LinuxPackages/...). Où avez-vous la mise à jour du noyau à partir de?
    • J'ai un simple hello world module. Et compilé sur le même noyau et il est compilé et chargé. Donc si il y avait un problème avec le noyau de versioning que même le hello world module ne serait pas chargé en premier lieu. Donc, je pense qu'il y a une autre question en elle.
    • Je ne pense pas que ce soit le cas. Si vous avez un module très simple que de très peu d'noyau symboles, alors que le module se charge parce que les symboles n'ont pas changé d'une version à l'autre. Mais si vous avez une plus compliqué module puis vous devrez le compiler à l'encontre de la même source (ou vous recevrez le message d'erreur que vous voyez).
    • ok, l'a obtenu. Merci dave.

    InformationsquelleAutor dave
  3. 2

    make-C /lib/modules/$(uname -r)/build M=$PWD modules,
    "$(uname -r)" montre que vous êtes de la compilation à l'encontre de la version du noyau que vous utilisez actuellement, donc vous devriez être en mesure de insmod le module dans le noyau actuel si vous n'avez pas changé les en-têtes.

    À partir de votre texte,
    "Juste pour vérifier que j'ai copié quelques fichiers à partir du noyau des répertoires dans mon répertoire de projet. Apporté des modifications à elle et inséré un peu plus de code."

    Si vous avez apporté des modifications à la source du noyau, alors vous pouvez avoir besoin de recompiler le noyau et démarrer avec la nouvelle mise à jour du noyau. Ensuite, vous devriez être en mesure de compiler votre kernel module avec la modification des en-têtes.

    • Je pense que j'ai fait quelques changements dans les en-têtes de certains pilotes de périphérique. Pouvez-vous me suggérer un lien qui montre MINIMUM d'étapes à suivre pour recompiler le noyau. "Aussi, une fois compilé ai-je besoin de recompiler le noyau de nouveau à l'avenir si j'ai fait des modifications pour les en-têtes dans le cadre du développement ? `
    • La compilation d'un noyau implique généralement de changer de config, puis de les construire et de les installer. J'ai fait surtout dans ubuntu, mais il n'est pas beaucoup différent à SuSe. Voici un lien qui présente les étapes à faire dans SuSe howtoforge.com/kernel_compilation_suse. Oui, nous avons besoin de recompiler le noyau si vous modifiez l'en-tête du noyau et de l'utilisation de la modification de l'en-tête de votre module dans le noyau.
    InformationsquelleAutor Randolf
  4. 1

    Vous ressemble construit contre le droit de noyau.quelque chose à voir avec la façon dont votre noyau est compilé. (Voir Config_conversions). Essayez de --force

    InformationsquelleAutor Brij