Re: 2.4.5-ac12 kernel oops

[klink@clouddancer.com (Colonel)]

In clouddancer.list.kernel, you wrote:
>
>On Mon, 25 Jun 2001 08:15:49 -0700 (PDT), 
>klink@clouddancer.com (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


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

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



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




-- 
"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