Bug 3151
Summary: | Incorrect kernel headers installed for SMP | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | daryll |
Component: | kernel | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.0 | CC: | gungnir, kilpatds |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
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: | |
Embargoed: |
Description
daryll
1999-05-30 06:00:08 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. *** 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. 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 ------- 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 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 |