我有一个相当大的驱动模块，我正在尝试为最近的Linux内核（3.4.4）编译。我可以用2.6.27.25内核成功编译和insmid相同的模块。GCC版本也不同，4.7.0 vs 4.3.0。请注意，这个模块相当复杂，我不能简单地浏览所有代码和所有makefile。
“插入”模块时，我得到一个无法分配内存，并带有以下跟踪：
vmap allocation for size 30248960 failed: use vmalloc=<size> to increase size.
vmalloc: allocation failure: 30243566 bytes
insmod: page allocation failure: order:0, mode:0xd2
Pid: 5840, comm: insmod Tainted: G O 3.4.4-5.fc17.i686 #1
Call Trace:
[<c092702a>] ? printk+0x2d/0x2f
[<c04eff8d>] warn_alloc_failed+0xad/0xf0
[<c05178d9>] __vmalloc_node_range+0x169/0x1d0
[<c0517994>] __vmalloc_node+0x54/0x60
[<c0490825>] ? sys_init_module+0x65/0x1d80
[<c0517a60>] vmalloc+0x30/0x40
[<c0490825>] ? sys_init_module+0x65/0x1d80
[<c0490825>] sys_init_module+0x65/0x1d80
[<c050cda6>] ? handle_mm_fault+0xf6/0x1d0
[<c0932b30>] ? spurious_fault+0xae/0xae
[<c0932ce7>] ? do_page_fault+0x1b7/0x450
[<c093665f>] sysenter_do_call+0x12/0x28
-- clip --
显而易见的答案似乎是模块分配了太多内存，但是：
因此，我怀疑新内核的问题与有限的内存没有直接关系。
新内核抱怨vmalloc（）的大小为30,000KB，但是在旧内核中，lsmid的大小为4,800KB。这些数字是否应该直接相关？是否有可能在构建过程中出现问题，并且请求RAM太多？当我编译两个. ko的部分大小时，我没有看到很大的差异。
所以我试图理解问题是从哪里来的。当我检查转储的堆栈时，我无法找到匹配的代码片段。似乎错误的vmalloc（）是由sys_init_module（）完成的，它是来自core/module. c的init_module（）。但是代码不匹配。当我从我的.ko检查目标代码时，init_module（）代码也不匹配。
我或多或少被阻止了，因为我对内核不够了解，所有的构建系统和模块加载都很难理解。错误发生在模块加载之前，因为我怀疑缺少一些功能，insmid此时没有报告这些错误。
我相信分配是在layout_and_allocate中完成的，它由load_module调用。两者都是静态函数，因此它们可能是内联的，因此不在堆栈上。
所以这不是你的代码完成的分配，而是Linux为了加载你的代码而完成的分配。
如果你的旧内核是4.8MB，而新内核是30MB，它可以解释为什么它会失败。
所以问题是为什么它这么大。
大小可能是由于代码量（不太可能增长这么多）或静态分配的数据。
一个可能的解释是您有一个大型静态分配的数组，其大小以Linux定义。如果大小显着增长，您的数组将增长。
猜测-大小为NR_CPUS的数组。
您应该能够使用诸如nm或obobdump之类的命令来查找这样的数组。但是我不确定具体如何做。
问题实际上是由于模块中的调试部分造成的。旧内核能够忽略这些部分，但新内核将它们计算在要分配的总大小中。但是，当在加载时从module. c启用pr_debug（）跟踪时，这些部分不会与其他部分一起转储。
如何摆脱它们并解决问题：
objcopy -R .debug_aranges \
-R .debug_info \
-R .debug_abbrev \
-R .debug_line \
-R .debug_frame \
-R .debug_str \
-R .debug_loc \
-R .debug_ranges \
orignal.ko new.ko
也有可能这个项目的特定构建文件正在为旧内核版本添加“定制”的调试信息，但是当尝试使用虚拟模块时，我发现附加了完全相同类型的调试部分，所以我宁愿怀疑内核或Fedora中关于模块管理的一些策略更改。
欢迎提供有关这些变化的任何信息。
