Bug 18230 - Kernel symbol versions wrong for enterprise kernel
Summary: Kernel symbol versions wrong for enterprise kernel
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-10-03 16:07 UTC by Jonathan Larmour
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-22 18:02:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jonathan Larmour 2000-10-03 16:07:12 UTC
The kernel symbol versions for the RH7 2.2.16-22enterprise kernel (at
least) do not correspond to what is in
/usr/src/linux/include/linux/modules. e.g. with my running enterprise

root@murgh modules]# grep __wake_up /proc/ksyms 
c0114088 __wake_up_Rsmp457689c6
[root@murgh modules]# grep -1 wake_up ksyms.ver 
#if  defined(__module__up) || defined(__module__BOOT)
#define __ver___wake_up	_ver_str(498cce34)
#elif  defined(__module__smp) || defined(__module__enterprise)
#define __ver___wake_up	_ver_str(983d74e1)

I don't know whether this also affects the SMP, UP or BOOT kernels.

This means that anyone who needs to build modules must rebuild their kernel
first to get the symbol versions to match.

Comment 1 Andrew McCallum 2000-10-10 21:52:27 UTC
The problem is that the symbol tables are assumed to be the same for the SMP 
and enterprise kernels.  They're not - at least not always.  Recompiling should 
work - but if you need to build modules against the enterprise kernel as 
distributed with Red Hat 7.0, you can edit the file


And add the correct appropriate symbol entries :
register_chrdev            : 3fcc10b2
interruptible_sleep_on     : 34474dfe
_wake_up                   : 457689c6

...and modify the if/then/else stuff to suit.  There are probably more invalid 
symbols, but those are the only ones I've come across.  If you find more, you 
can get the correct ones from the running enterprise kernel in /proc/ksyms.

Comment 2 Jonathan Larmour 2000-10-10 22:02:12 UTC
Yep, thanks for the analysis which is fair enough. I'm happy now personally
having rebuilt the kernel, but my main concern was the (inevitable) kernel
errata and making sure it does have correct symbols so this isn't a problem in



Comment 3 Jonathan Larmour 2000-10-26 19:25:27 UTC
Is this going to be resolved in the upcoming kernel errata? I hope so!

Comment 4 jpranevich 2002-04-22 18:02:02 UTC
This is still an issue, at least in the latest 6.2 errata. Has this been 
resolved for kernels in the 7.x series?

Comment 5 Michael K. Johnson 2002-05-02 16:41:00 UTC
Yes, it's resolved for 7.1 and 7.2, where the "enterprise" kernel differs
only in configuration from the main kernel, thus making the symbols be
calculated correctly.

The reason the symbols don't match the enterprise kernel in 6.2 is that
we have to apply a patch for the enteprise kernel only; we have to do
that because of limitations with the 2.2 kernel.  That won't be fixed.
It's not fixable with a reasonable amount of effort in any way I can
think of.

So I don't know whether to close this as CURRENTRELEASE or WONTFIX...  :-)

Note You need to log in before you can comment on or make changes to this bug.