最新消息:20190717 VPS服务器:Vultr新加坡,WordPress主题:大前端D8,统一介绍入口:关于

【已解决】request_module: runaway loop modprobe binfmt-e514

工作和技术 crifan 1245浏览 0评论

【问题】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

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
53 queries in 0.253 seconds, using 18.85MB memory