Skip to main content

Browse the archive

https://github.com/torvalds/linux
17 May 2024, 11:00:25 UTC
Revision 61074287c2965edf0fc75b54ae8f4ce99f182669 authored by Rusty Russell on 15 December 2011, 03:04:50 UTC, committed by Chris Ball on 19 December 2011, 23:56:09 UTC 
mmc: vub300: fix type of firmware_rom_wait_states module parameter
 
You didn't mean this to be a bool.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
1 parent 5c7f0e0
Raw File
Tip revision: 61074287c2965edf0fc75b54ae8f4ce99f182669 authored by Rusty Russell on 15 December 2011, 03:04:50 UTC
mmc: vub300: fix type of firmware_rom_wait_states module parameter
Tip revision: 6107428
debugging-modules.txt 
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.
back to top