leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: merge debugging-modules.txt into sysctl/kernel.rst

Browse Source 
This fits nicely in sysctl/kernel.rst, merge it (and rephrase it)
instead of linking to it.

Signed-off-by: Stephen Kitt <steve@sk2.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Stephen Kitt 2020-02-18 13:59:17 +01:00 committed by Jonathan Corbet
parent a3cb66a508
commit 0317c5371e
2 changed files with 13 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -387,7 +387,19 @@ This flag controls the L2 cache of G3 processor boards. If
modprobe
========
See Documentation/debugging-modules.txt.
This gives the full path of the modprobe command which the kernel will
use to load modules. This can be used to debug module loading
requests::
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
This only applies when the *kernel* is requesting that the module be
loaded; it won't have any effect if the module is being loaded
explicitly using ``modprobe`` from userspace.
modules_disabled

22
Documentation/debugging-modules.txt
View File

@ -1,22 +0,0 @@
Debugging Modules after 2.6.3
-----------------------------
In almost all distributions, the kernel asks for modules which don't
exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to
"succeed" in this case is hacky and breaks some setups, and also we
want to know if it failed for the fallback code for old aliases in
fs/char_dev.c, for example.
In the past a debugging message which would fill people's logs was
emitted. This debugging message has been removed. The correct way
of debugging module problems is something like this:
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
Note that the above applies only when the *kernel* is requesting
that the module be loaded -- it won't have any effect if that module
is being loaded explicitly using "modprobe" from userspace.