Bug 3151

Summary: Incorrect kernel headers installed for SMP
Product: [Retired] Red Hat Linux Reporter: daryll
Component: kernelAssignee: Cristian Gafton <gafton>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: gungnir, kilpatds
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-06-18 20:05:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description daryll 1999-05-30 06:00:08 UTC
When you install an SMP kernel, the non-SMP kernel headers
are installed. This makes building a stand alone device
driver impossible, as the module versions don't match the

Comment 1 Jeff Johnson 1999-06-08 22:22:59 UTC
*** Bug 3344 has been marked as a duplicate of this bug. ***

$ rpm -qf /usr/include/linux/autoconf.h
$ grep SMP /usr/include/linux/autoconf.h

Since I'm running an SMP kernel on my home system, this
obviously makes it more difficult to compile kernel-modules
to either play with myself or for products such as 4-Front's
OSS sound drivers.

Comment 2 Jeff Johnson 1999-06-08 22:23:59 UTC
*** Bug 3072 has been marked as a duplicate of this bug. ***

Building Daryll Strauss' 3dfx.o device on for an SMP kernel
(2.2.5-15smp) creates a 3dfx.o with the version 2.2.5-15.

I had previously configured the kernel with SMP.

I got the device to build with the correct version by
manually editing /usr/src/linux/include/linux/version.h
and adding the 'smp' postfix to UTS_RELEASE.

------- Additional Comments From jturner  05/26/99 13:51 -------
I have seen this discrepancy in the test lab, but have not had trouble
building modules.  I am forwarding this issue to a developer for
further review.

Comment 3 Cristian Gafton 1999-06-18 17:35:59 UTC
The default installed headers are for uniprocessor. The defaults have
to be generic, because there is no way of telling what kernel the user
is running.

------- Email Received From  Daryll Strauss <daryll> 06/18/99 16:02 -------

Comment 4 Cristian Gafton 1999-06-18 20:04:59 UTC
Can't you at least provide your default SMTP headers in a separate
package? That way people with SMP can install it if they need
it. Otherwise they only way they can get valid headers is to do a full
kernel compile and install. That seems like a reasonable compromise.

                                              - |Daryll

Comment 5 Cristian Gafton 1999-06-18 20:05:59 UTC
No, because when i generate the rpm I can only have one single file
for eahc header. I can not have /usr/include/linux/foo.h as two
different files in two different packages.

That would be solved by having different .src.rpms for the smp and non
smp kernels, and there is no way I am going back to that mess.

------- Additional Comments From   06/18/99 20:58 -------
I have a .spec file that creates additional packages for the generated
headers.  It has some problems that should be easy for a RPM expert to
fix related to the symlink for /usr/include/linux.

I do not believe that it is the correct solution, but I'm willing to
email it to anyone who wants a copy.

Why can't you put the generated header files as part of the kernel


And as part of either the package install or the boot procedure
symlink those to the non-foo names?  You want me to try and come up
with a .spec file for this as well?

------- Additional Comments From   06/18/99 22:50 -------
Are you really saying "yes, it is broken, but it is too
much trouble to fix?" That's not a good answer.

Realize that any stand-alone kernel module that tries to use module
versions is effected by this. That means PCMCIA, serial drivers, etc
will all have this problem if a user attempts to build them.

I'm open to any suggestion for a work around. My current solution is
to tell the users to reconfigure, recompile, and reinstall their
kernel, because Red Hat ships a broken kernel configuration, but I
would think we could come up with something better.

						- |Daryll