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
[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.
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.
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
Is this going to be resolved in the upcoming kernel errata? I hope so!
This is still an issue, at least in the latest 6.2 errata. Has this been
resolved for kernels in the 7.x series?
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
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
So I don't know whether to close this as CURRENTRELEASE or WONTFIX... :-)