Revision 0ea457839d050370e0f7c75c81f9abd573e1f420 authored by Linus Torvalds on 10 February 2010, 15:15:21 UTC, committed by Linus Torvalds on 10 February 2010, 15:15:21 UTC
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (29 commits)
  drivers/net: Correct NULL test
  MAINTAINERS: networking drivers - Add git net-next tree
  net/sched: Fix module name in Kconfig
  cxgb3: fix GRO checksum check
  dst: call cond_resched() in dst_gc_task()
  netfilter: nf_conntrack: fix hash resizing with namespaces
  netfilter: xtables: compat out of scope fix
  netfilter: nf_conntrack: restrict runtime expect hashsize modifications
  netfilter: nf_conntrack: per netns nf_conntrack_cachep
  netfilter: nf_conntrack: fix memory corruption with multiple namespaces
  Bluetooth: Keep a copy of each HID device's report descriptor
  pktgen: Fix freezing problem
  igb: make certain to reassign legacy interrupt vectors after reset
  irda: add missing BKL in irnet_ppp ioctl
  irda: unbalanced lock_kernel in irnet_ppp
  ixgbe: Fix return of invalid txq
  ixgbe: Fix ixgbe_tx_map error path
  netxen: protect resource cleanup by rtnl lock
  netxen: fix tx timeout recovery for NX2031 chip
  Bluetooth: Enter active mode before establishing a SCO link.
  ...
2 parent s ac73fdd + 44bfce5
Raw File
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