Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

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