Both msdos and raid are in your kernel, msdos is not a module.
Don't be misled by ksymoops reporting duplicate symbols. It reads the
entire symbol map and reports discrepancies as it does so, mainly to
pick up idiots who feed /proc/ksyms from 2.2 and System.map from 2.4.
Don't laugh, it happens! Unless the trace shows raid or msdos are
implicated in the oops, you can ignore the ksymoops warning.
>>ksymoops has a hierarchy of trust. System.map is more trustworthy than
>>/proc/ksyms because ksyms changes, especially if you rebooted after the
>>oops and before running ksymoops.
>
>Hmm, I would have thought that /proc was more up to date, because it
>would reflect changes. No reboot, never even considered it (I've
>rescued too many junior sysadmins that think rebooting is _the_ answer).
/proc/ksyms is dynamic, it changes as modules are loaded and unloaded.
And often the oops is so bad that the machine is dead so reboot is the
only option, ksyms after reboot may be for a completely different
kernel. If you want accurate ksyms and lsmod data to feed into
ksymoops, 'man insmod' and read section 'KSYMOOPS ASSISTANCE'.
-
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/