在对一个ko文件进行内核模块加载insmod的时候竟然出现这个奇怪的问题:

在解决这个问题之前我在网上查了半天,各种说法的都有也都试过了,主要是试过一下方法:

1、你的内核版本和你Makefile制定的不一样,编译模块时选择的Linux头文件目录与当前运行的系统版本不匹配,使用命令:uname -r查看当前运行的内核版本,然后选择正确的Linux头文件路径;他们提供的解决方法:

直接将Makefile文件中原来指定内核的语句改为通用语句:

KERN_VER = $(shell uname -r)

KERN_DIR = /lib/modules/$(KERN_VER)/build 

我试过了这个方法不可行,因为如果是这个问题就不会报错:invalid parameters了,而是会报错Invalid module format;

2、生成的模块名字不能以module命名,改成其他名字就好了.

我就根本没有一module命名ko文件(笑哭);

3、还有说什么文件权限的问题,要修改文件的权限(笑哭);还有说必须把ko文件放在自己编译的内核目录下:/lib/module/5.0.0-32-generic目录下,要copy过去(胡扯,放哪里都一样)

接下来我就提供我解决这个问题的过程和方法:

a. 首先要dmesg一下,查看系统日志文件信息,一般这里可以看出具体的原因是什么,比直接在网上找问题靠谱了,因为网友的环境和出现问题的原因肯定是有可能不一样的,千奇百怪的,所以自己查日志最靠谱了,于是查到如下问题:

CHRDEV "mmap_driver1" major requested (990) is greater than the maximum (511)

这样就可以瞬间知道原来在被编译的源代码文件中的一个参数主设备号major设置成990过大超过新版本的最大限值511 ,改成小于511就好了;

#define MAJOR_NUM 990 改成 #define MAJOR_NUM 490

这样问题就解决了;

我还查到一个网友出现这个问题是因为

" no symbol version for 之前的函数名",说明该模块找不到所依赖的函数

 

总结: 

所以出现 insmod内核模块问题: Invalid parameters一定是因为被编译的源代码的有的参数是无效的,而一般这样的问题不会在编译的过程中报错,而是在运行的过程中报错,所以呼吁大家一定自己dmesg命令一下,查看日志信息,才能又快又准的解决自己遇到的bug;要学会调试。

 

Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐