Skip to contentSkip to conversation

2.4.5-ac12 kernel oops

DISCUSSION Colonel 2 participants 2 messages Jun 25, 2001 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Colonel

author
#1 lore raw
Quoted 9 lines · you
Quoted 3 lines · On Mon, 25 Jun 2001 08:15:49 -0700 (PDT), [email protected] (Colonel) wrote:

ksymoops 2.4.1 on i686 2.4.5-ac12. Options used
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01aad00, System.map says c014cba0. Ignoring ksyms_base entry Why the symbol mismatch?

The mismatch is caused by two variables called partition_name. What does 'nm vmlinux | grep partition_name' show? Probably one

Can't run that, but :

grep "partition_name" System.map-2.4.5-ac12
00000000c014cba0 t partition_name
00000000c01aad00 T partition_name

Quoted 2 lines

partition_name at c01aad00 and another at c014cba0. Both fs/partitions/msdos.c and drivers/md/md.c define that symbol, md

and I have both in the kernel.

Quoted 2 lines

exports its version. A good reason why exported symbols should have unique names.

Only the raid5 was active, the msdos stuff is a module for 'just in case'. Something else triggered this, I've run raid for a long time without problems.

Quoted 5 lines
Quoted 1 line

Why ignore /proc over the System.map?

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).

Signature · 7 lines
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

ditto
#2 lore raw
Quoted 8 lines · On Mon, 25 Jun 2001 09:02:19 -0700 (PDT), [email protected] (Colonel) wrote:
Quoted 2 lines · Keith Owens

partition_name at c01aad00 and another at c014cba0. Both fs/partitions/msdos.c and drivers/md/md.c define that symbol, md

and I have both in the kernel.
Only the raid5 was active, the msdos stuff is a module for 'just in case'. Something else triggered this, I've run raid for a long time without problems.

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.

Quoted 7 lines
Quoted 3 lines

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'.