Messages in this thread | | | Date | Wed, 14 Jan 2004 15:48:36 -0800 | From | "Randy.Dunlap" <> | Subject | Re: modprobe failed: digest_null |
| |
On Tue, 13 Jan 2004 15:38:45 -0800 (PST) "David Rees" <drees@greenhydrant.com> wrote:
> kernel: request_module: failed /sbin/modprobe -- digest_null. error = 256
Chris Wright tells me that this is a null digest crypto plugin for testing. It might show up in your /etc/modprobe.conf file (or it might not).
| request_module: failed /sbin/modprobe -- n. error = 256
This is looking for a module named "n". Don't know where that comes from.
In both cases, error = 256 is 0x100, which is the value returned from kernel/kmod.c::call_usermodehelper(), which execs /sbin/modprobe in this case. /sbin/modprobe does exit(1) for modules that are not found, and that 1 becomes 0x100 in call_usermodehelper().
| Running on Fedora Core 1 compiled with gcc 3.3.2. Didn't see these with | 2.6.0.
and I wrote yesterday: | request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
This one comes from drivers/char/lp.c::lp_init() calling parport_register_driver(), which calls get_lowlevel_driver(), which calls request_module("parport_lowlevel"). Since I have lp.o and parport code built into the kernel image, these calls happen during early init, before <system_running> is set to 1, so call_usermodehelper() returns -EBUSY (-16 on x86).
| request_module: failed /sbin/modprobe -- fb0. error = 256
Same as first case above, but for a framebuffer device.
I don't know what needs to be done about these, if anything.
Comments, suggestions?
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |