ksyms, kksymoops, modules, et.al.

ksyms, kksymoops, modules, et.al.

[Kevin Brosius]

So what's going on with ksyms in 2.5.48 (and bk trees since the module
loader change, as far as I can tell)?  I no longer see /proc/ksyms and
kernel oops's don't get decoded automatically either.

I also notice that the 'modules_install' target is populating the
/lib/modules/version#/kernel directory with a flat collection of all the
modules at that one directory level.  There are no subdirectories.  Is
this intentional?  This seems to break depmod and insmod for me, unless
I use insmod with a direct path and full filename.


In a (possibly related) test, if I add to .config:

CONFIG_KALLSYMS=y

then I see the following interesting behavior.  Note that I do have new
modutils installed, so insmod.old does exist in /sbin

---------------
make[1]: `scripts/kconfig/conf' is up to date.
./scripts/kconfig/conf -s arch/i386/Kconfig
.config:1309: trying to assign nonexistent symbol KALLSYMS

<snip>

  /sbin/kallsyms .tmp_vmlinux1 > .tmp_kallsyms1.o
Kernel requires old insmod, but couldn't run insmod.old: No such file or
directory
make: *** [.tmp_kallsyms1.o] Error 2
---------------

Is there some documented change (which I failed to locate) to ksyms I
should be using to decode oops's?  Oh, and the make removes the entry
for 'CONFIG_KALLSYMS'...  Help :)

-- 
Kevin

Re: ksyms, kksymoops, modules, et.al.

[Jeff Garzik]

Kevin Brosius wrote:

> So what's going on with ksyms in 2.5.48 (and bk trees since the module
> loader change, as far as I can tell)?  I no longer see /proc/ksyms and
> kernel oops's don't get decoded automatically either.



It's currently broken due to the new module code... ping Rusty for a fix ;-)