File: debugging-modules.txt

package info (click to toggle)
linux 3.16.7-ckt9-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 740,624 kB
  • ctags: 2,385,278
  • sloc: ansic: 12,217,941; asm: 277,354; perl: 53,978; xml: 47,771; makefile: 30,485; sh: 8,063; python: 6,597; cpp: 5,127; yacc: 4,254; lex: 2,215; awk: 741; pascal: 231; lisp: 218; sed: 30
file content (22 lines) | stat: -rw-r--r-- 954 bytes parent folder | download | duplicates (32)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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.