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 - Incorrect kernel headers installed for SMP
Summary: Incorrect kernel headers installed for SMP
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
: 3072 3344 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-30 06:00 UTC by daryll
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-06-18 20:05:50 UTC


Attachments (Terms of Use)

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

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
kernel-headers-2.2.5-22
$ grep SMP /usr/include/linux/autoconf.h
#undef
CONFIG_SMP

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@redhat.com  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@precisioninsight.com> 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
package?

/usr/include/linux/modules-<foo>/
/usr/include/linux/versions.h-<foo>
/usr/include/linux/autoconf.h-<foo>

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


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