ksymoops doesn't know what modules were loaded at the time
of the crash, and it doesn't know where they were loaded.
The `klogd -x' problem has been with us for *years* and
distributors still persist in turning it on.
> Guess why these entries are in /proc/ksyms?
>
> c48a2300 __insmod_3c589_cs_S.bss_L4 [3c589_cs]
> c48a0000 __insmod_3c589_cs_O/lib/modules/2.4.17-xfs/kernel/drivers/net/pcmcia/3c589_cs.o_M3C332CFF_V132113 [3c589_cs]
> c48a22a0 __insmod_3c589_cs_S.data_L96 [3c589_cs]
> c48a1820 __insmod_3c589_cs_S.rodata_L1152 [3c589_cs]
> c48a0060 __insmod_3c589_cs_S.text_L6064 [3c589_cs]
>
> ksymoops uses the __insmod entries to work out exactly where each
> module is, it gives an accurate backtrace with modules. man insmod for
> details.
It assumes too much. Arjan has a kksymoops thingy which does the symbol
resolution at crash-time. This seems much more reliable to me. It also
handles the common case where the running vmlinux/System.map/etc no longer
exist.
> Kernel debuggers like kgdb and kdb use kallsyms which has full support
> for modules. kgdb can also use the __insmod entries in /proc/ksyms to
> tell gdb where each module was loaded.
>
> ksymoops has a save map option (-s) which writes out the combined
> system map, including the kernel and all symbols from all modules.
>
> Sure, a dynamic system requires a little more work, but it has all been
> done. Just kill the broken klogd code so it stops corrupting log data.
Keith, I have spent a *lot* of time working weird kernel bugs
with people via email. Usually, things peter out simply because
the other party lacks the expertise or time to keep on doing
things. So the bug doesn't get fixed.
I would prefer that all this become easier, simpler and more reliable.
We need a damn good reason for deprecating statically linked kernels
and certainly none has been presented yet.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/