【问题】request_module: runaway loop modprobe binfmt-e514
在uboot里面，原先是挂载的cramfs，是成功的：
。。。。。。。。。。。。。
[ 0.960000] VFS: Mounted root (cramfs filesystem) readonly.
[ 0.970000] Freeing init memory: 100K
command=’/bin/mount -o remount,ro /’ action=1 tty=’/dev/null’
command=’/bin/mount -t proc proc /proc’ action=1 tty=’/dev/null’
。。。。。。。。。。。。。
后来，把挂载的根文件系统改成了ext2，然后把ext2 的rootfs烧写到LBA nand里面。启动kernel后，在最后挂载rootfs失败，出现如下错误：
Uncompressing Linux……………………………………………………………………………………. done, booting the kernel.
。。。。。。
[ 0.000000] Kernel command line: root=/dev/lba rw init=/linuxrc console=ttyS0,115200 mem=64M rootfstype=ext2
。。。。。
[ 0.960000] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
[ 0.960000] VFS: Mounted root (ext2 filesystem).
[ 0.970000] Freeing init memory: 100K
[ 1.080000] request_module: runaway loop modprobe binfmt-e514
[ 1.080000] request_module: runaway loop modprobe binfmt-e514
[ 1.090000] request_module: runaway loop modprobe binfmt-e514
[ 1.100000] request_module: runaway loop modprobe binfmt-e514
[ 1.110000] request_module: runaway loop modprobe binfmt-e514
【解决过程】
1.百度了一下，有人说：
“最近配内核遇到了这个错误：request_module: runaway loop modprobe binfmt-464c
一开始以为是内核没有配好，用以前配好的一份for 2.5.25-gentoo-r9的内核.config编译试试。
编译发现还是有这个错误，于是怀疑有东西升错级了。但是用回stage3-i686的包却还是不行，问题就回到内核配置上。经过几轮的搜索终于在gentoo论坛上找到这么一篇：[solved]request_module: runaway loop modprobe binfmt464上面说选上ELF二进制文件的支持（CONFIG_BINFMT_ELF=y）。哈哈，使用他的方法后果然启动成功！”
所以去kernel的menuconfig中找到对应的配置此选项地方：
Userspace binary formats —> [*] Kernel support for ELF binaries
发现此处本身已经选中了，因此不是这个原因。
2.google找到这个人的解决过程：
“> How can I discover
> what is trying to load binfmt-0000 and why is it looping?
Start with this, I guess..
— a/kernel/kmod.c~a
+++ a/kernel/kmod.c
@@ -98,10 +98,12 @@ int request_module(const char *fmt, …)
atomic_inc(&kmod_concurrent);
if (atomic_read(&kmod_concurrent) > max_modprobes) {
/* We may be blaming an innocent here, but unlikely */
– if (kmod_loop_msg++ < 5)
+ if (kmod_loop_msg++ < 5) {
printk(KERN_ERR
"request_module: runaway loop modprobe %sn",
module_name);
+ dump_stack();
+ }
atomic_dec(&kmod_concurrent);
return -ENOMEM;
}
How interesting… added that to kmod.c, rebuilt without change to
config, reboot…. machine booted perfectly!”
因此也去把那个dump_stack加上，结果还是出错：
[ 0.960000] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
[ 0.960000] VFS: Mounted root (ext2 filesystem).
[ 0.970000] Freeing init memory: 100K
[ 1.080000] request_module: runaway loop modprobe binfmt-e514
[ 1.080000] [<c0026298>] (dump_stack+0x0/0x14) from [<c0050474>] (request_module+0x134/0x158)
[ 1.090000] [<c0050340>] (request_module+0x0/0x158) from [<c0088e18>] (search_binary_handler+0x160/0x1dc)
[ 1.100000] r3:0000000f r2:fffffff8 r1:0000e514 r0:c02a2a34
[ 1.110000] r7:c3ebff70 r6:fffffff8 r5:c3ea5a00 r4:00000000
[ 1.110000] [<c0088cb8>] (search_binary_handler+0x0/0x1dc) from [<c008a4ac>] (do_execve+0x120/0x1d4)
[ 1.120000] [<c008a38c>] (do_execve+0x0/0x1d4) from [<c00250fc>] (kernel_execve+0x40/0x88)
[ 1.130000] [<c00250bc>] (kernel_execve+0x0/0x88) from [<c0050570>] (____call_usermodehelper+0xd8/0xe4)
[ 1.140000] r7:c3dfeaa0 r6:00000000 r5:c3ebe000 r4:00000000
[ 1.150000] [<c0050498>] (____call_usermodehelper+0x0/0xe4) from [<c0043304>] (do_exit+0x0/0x87c)
[ 1.160000] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 1.160000] request_module: runaway loop modprobe binfmt-e514
[ 1.170000] [<c0026298>] (dump_stack+0x0/0x14) from [<c0050474>] (request_module+0x134/0x158)
[ 1.180000] [<c0050340>] (request_module+0x0/0x158) from [<c0088e18>] (search_binary_handler+0x160/0x1dc)
[ 1.190000] r3:0000000f r2:fffffff8 r1:0000e514 r0:c02a2a34
[ 1.190000] r7:c3ebff70 r6:fffffff8 r5:c3ea5a00 r4:00000000
[ 1.200000] [<c0088cb8>] (search_binary_handler+0x0/0x1dc) from [<c008a4ac>] (do_execve+0x120/0x1d4)
[ 1.210000] [<c008a38c>] (do_execve+0x0/0x1d4) from [<c00250fc>] (kernel_execve+0x40/0x88)
[ 1.220000] [<c00250bc>] (kernel_execve+0x0/0x88) from [<c0050570>] (____call_usermodehelper+0xd8/0xe4)
[ 1.230000] r7:c3dfeaa0 r6:00000000 r5:c3ebe000 r4:00000000
[ 1.230000] [<c0050498>] (____call_usermodehelper+0x0/0xe4) from [<c0043304>] (do_exit+0x0/0x87c)
[ 1.240000] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 1.250000] request_module: runaway loop modprobe binfmt-e514
[ 1.260000] [<c0026298>] (dump_stack+0x0/0x14) from [<c0050474>] (request_module+0x134/0x158)
[ 1.270000] [<c0050340>] (request_module+0x0/0x158) from [<c0088e18>] (search_binary_handler+0x160/0x1dc)
[ 1.280000] r3:0000000f r2:fffffff8 r1:0000e514 r0:c02a2a34
[ 1.280000] r7:c3ec3f70 r6:fffffff8 r5:c3ea5a00 r4:00000000
[ 1.290000] [<c0088cb8>] (search_binary_handler+0x0/0x1dc) from [<c008a4ac>] (do_execve+0x120/0x1d4)
[ 1.300000] [<c008a38c>] (do_execve+0x0/0x1d4) from [<c00250fc>] (kernel_execve+0x40/0x88)
[ 1.310000] [<c00250bc>] (kernel_execve+0x0/0x88) from [<c0050570>] (____call_usermodehelper+0xd8/0xe4)
[ 1.320000] r7:c3dfeaa0 r6:00000000 r5:c3ec2000 r4:00000000
[ 1.320000] [<c0050498>] (____call_usermodehelper+0x0/0xe4) from [<c0043304>] (do_exit+0x0/0x87c)
[ 1.330000] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 1.340000] request_module: runaway loop modprobe binfmt-e514
[ 1.340000] [<c0026298>] (dump_stack+0x0/0x14) from [<c0050474>] (request_module+0x134/0x158)
[ 1.350000] [<c0050340>] (request_module+0x0/0x158) from [<c0088e18>] (search_binary_handler+0x160/0x1dc)
[ 1.360000] r3:0000000f r2:fffffff8 r1:0000e514 r0:c02a2a34
[ 1.370000] r7:c3ec3f70 r6:fffffff8 r5:c3ea5a00 r4:00000000
[ 1.370000] [<c0088cb8>] (search_binary_handler+0x0/0x1dc) from [<c008a4ac>] (do_execve+0x120/0x1d4)
[ 1.380000] [<c008a38c>] (do_execve+0x0/0x1d4) from [<c00250fc>] (kernel_execve+0x40/0x88)
[ 1.390000] [<c00250bc>] (kernel_execve+0x0/0x88) from [<c0050570>] (____call_usermodehelper+0xd8/0xe4)
[ 1.400000] r7:c3dfeaa0 r6:00000000 r5:c3ec2000 r4:00000000
[ 1.410000] [<c0050498>] (____call_usermodehelper+0x0/0xe4) from [<c0043304>] (do_exit+0x0/0x87c)
[ 1.420000] r7:00000000 r6:00000000 r5:00000000 r4:00000000
[ 1.430000] request_module: runaway loop modprobe binfmt-e514
[ 1.430000] [<c0026298>] (dump_stack+0x0/0x14) from [<c0050474>] (request_module+0x134/0x158)
[ 1.440000] [<c0050340>] (request_module+0x0/0x158) from [<c0088e18>] (search_binary_handler+0x160/0x1dc)
[ 1.450000] r3:0000000f r2:fffffff8 r1:0000e514 r0:c02a2a34
[ 1.460000] r7:c3ecff70 r6:fffffff8 r5:c3ea5a00 r4:00000000
[ 1.460000] [<c0088cb8>] (search_binary_handler+0x0/0x1dc) from [<c008a4ac>] (do_execve+0x120/0x1d4)
[ 1.470000] [<c008a38c>] (do_execve+0x0/0x1d4) from [<c00250fc>] (kernel_execve+0x40/0x88)
[ 1.480000] [<c00250bc>] (kernel_execve+0x0/0x88) from [<c0050570>] (____call_usermodehelper+0xd8/0xe4)
[ 1.490000] r7:c3dfeaa0 r6:00000000 r5:c3ece000 r4:00000000
[ 1.500000] [<c0050498>] (____call_usermodehelper+0x0/0xe4) from [<c0043304>] (do_exit+0x0/0x87c)
[ 1.510000] r7:00000000 r6:00000000 r5:00000000 r4:00000000
【解决问题】
调试到最后，结果发现是自己的块设备驱动的问题。
自己块设备驱动，在处理
bio_for_each_segment(bvec, bio, i)
时候，每处理完其中一个，没有及时正确更新新的buffer的指针，导致数据一直都是被读到最原始的buffer：buf = bio_data(bio); 里面去了，所以，后面的所有的数据，都是每次后读出的数据，覆盖了原先的数据，而且还都是放在一个地方，后面程序，当然不可能正常运行了。。。
所以办法就是，算出正确的buffer的地址：
bio_for_each_segment(bvec, bio, i)
{
sec_len = bvec->bv_len >> LBA_SECTOR_SIZE_SHIFT;
/* !!! update buffer pointer */
//buf += bvec->bv_len;
buf = (u8*)((u8*)page_address(bvec->bv_page) + bvec->bv_offset);
if(rw)
{
/* write */
ret |= as352x_lba->lba_info->sectors_write(as352x_lba->lba_info, sector, sec_len, buf);
}
else
{
/* read */
ret |= as352x_lba->lba_info->sectors_read(as352x_lba->lba_info, sector, sec_len, buf);
}
/* update sectors */
sector += sec_len;
}
这样，每次读出的数据，才能正确放到正确的地方。
【后记】
实在有点无语，因为，块设备驱动中，数据读写函数自己没写好，导致后面出现其他异常问题。
这其实也没什么，关键是，驱动错了，并没有全错，而是如果每次此块设备只处理一个请求，就不会涉及第二次buffer地址更新的问题，也就可以正常工作，这也就是我之前基于此块设备，用cramfs的时候，结果就是可以正常mount上cramfs文件系统，并且可以正常使用的。而换了ext2，由于其中数据请求，多数是一次请求多个block，会涉及到新的buffer地址更新的问题。所以，才使用无法正常使用。
此问题，导致之前出现很多其他不相关的现象，比如上面的
request_module: runaway loop modprobe binfmt-e514
还有后来的，以为buildroot中制作的ext2文件系统那个文件rootfs.arm.ext2有问题呢，结果自己又去找了对应工具e2fsprogs的源码回来，自己单独编译生成对应的mke2fs的一系列相关工具，去操作/dev/lba这个块设备等等，结果最后的最后，发现是自己驱动的问题，真是很无语。。。
转载请注明：在路上 » 【已解决】request_module: runaway loop modprobe binfmt-e514