|Summary:||Fedora 0.94 test2 kernel does not compile with default config|
|Product:||[Fedora] Fedora||Reporter:||Ben Hsu <benhsu>|
|Component:||kernel||Assignee:||Ingo Molnar <mingo>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||rawhide||CC:||behdad, davej, esimmonds, hancockrwd, jwboyer, lohphat, yousefourabi|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-05-26 14:13:37 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Ben Hsu 2003-09-30 03:38:36 UTC
Version-Release number of selected component (if applicable): 2.4.22-1.2061 How reproducible: 100% Steps to Reproduce: 1. make mrproper 2. cp configs/kernel-2.4.22-i686.config ./.config 3. make oldconfig dep clean bzImage Actual results: compilation fails with: kernel/kernel.o(.text+0xf9f): In function `schedule': : undefined reference to `active_load_balance' Expected results: make completes successfully Additional info: This looks like its because the definition of active_load_rebalance as well as those of several functions active_load_rebalance depends on is in an #ifdef CONFIG_SMP starting on line 1087. Compiling with SMP turned on fixed this problem. Probably unrelated, but when I was debugging this I noticed: cp configs/kernel-2.4.22-i686.config ./.config grep CONFIG_SHARE_RUNQUEUE .config #nothing make oldconfig grep CONFIG_SHARE_RUNQUEUE .config #set to "y" make xconfig<save without making any changes> grep CONFIG_SHARE_RUNQUEUE .config #nothing again!
Comment 1 Bill Nottingham 2003-09-30 03:50:49 UTC
Does this persist with 2.4.22-1.2075?
Comment 2 Ben Hsu 2003-10-02 02:33:35 UTC
Yes, it still reproduces in 2.4.22-1.2081
Comment 3 Behdad Esfahbod 2003-10-07 03:48:38 UTC
The problem, after a week of banging my head against the wall, is with compiler. Well, kernel does not compile with default gcc (3.3). One should do export CC=gcc32 and then try compiling kernel. Two things to do: 1. Note explicitly in release-notes that you should do export CC=gcc32 before compiling any Linux kernel, for the time being. (Should I file another bug for release-notes?) 2. Better hack kernel Makefiles to fall back to gcc32 if CC is not defined. At least we know that the kernel is not going to be compiled with the default gcc, so the Makefile can decide itself. And better the problem be solved before beta3. It's quite simple one, but really annoying.
Comment 4 Edward Simmonds 2003-10-19 18:49:52 UTC
Latest kernel (2.4.22-1.2097) also does not compile. In fact, I have been unable to compile ANY kernel in Fedora, including a vanilla 2.4.22 from kernel.org or any of the kernel-sources provided by RedHat. I am using the i686 config right out of the configs directory in each case. I am actually wondering how anyone managed to package the binary kernel RPM's in the first place. gcc32 does not seem to work either. This is really causing problems for me. Two examples follow. These both use the default i686 config. latest kernel (2097) (i686 config from configs directory): make: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/nls' make: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/nls' make -C partitions make: Entering directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/partitions' make all_targets make: Entering directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/partitions' gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-1.2097.nptl/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=check -DEXPORT_SYMTAB -c check.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-1.2097.nptl/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=mac -c -o mac.o mac.c make: *** [first_rule] Segmentation fault make: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/partitions' make: *** [_subdir_partitions] Error 2 make: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs' make: *** [_dir_fs] Error 2 vanilla 2.4.22 kernel with gcc32: gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=vm86 -c -o vm86.o vm86.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ptrace -c -o ptrace.o ptrace.c gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=i8259 -c -o i8259.o i8259.c gcc: Internal error: Segmentation fault (program as) Please submit a full bug report. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. make: *** [i8259.o] Error 1 make: Leaving directory `/usr/src/linux-2.4.22/arch/i386/kernel' make: *** [_dir_arch/i386/kernel] Error 2 # rpm -qa | grep glibc glibc-2.3.2-98 glibc-kernheaders-2.4-8.24 glibc-headers-2.3.2-98 glibc-devel-2.3.2-98 glibc-common-2.3.2-98 # rpm -qa | grep gcc compat-gcc-c++-7.3-2.96.118 gcc-c++-3.3.1-6 gcc-gnat-3.3.1-6 libgcc-3.3.1-6 gcc32-3.2.3-6 gcc-3.3.1-6 gcc-java-3.3.1-6 compat-gcc-7.3-2.96.118 gcc-g77-3.3.1-6
Comment 5 Ben Hsu 2003-10-20 16:08:01 UTC
export CC=gcc32 works for me. Please close this bug as a user error. Sorry for the trouble. Behdad, it looks like you're hitting a different bug against gcc. You should probably file another bug against gcc/as with the stack trace from the core file.
Comment 6 Ben Hsu 2003-10-20 16:09:23 UTC
Sorry above comments should be for Edward not Behdad :(
Comment 7 Dave Jones 2003-11-10 18:03:28 UTC
*** Bug 109540 has been marked as a duplicate of this bug. ***
Comment 8 Dave Jones 2003-11-10 18:04:49 UTC
The gcc32 'workaround' mentioned above is bogus. This bug is still there, and only goes away when you do make oldconfig twice.
Comment 9 Josh Boyer 2003-11-10 21:18:40 UTC
Created attachment 95889 [details] patch for configs/kernel-2.4.22-i686.config this patch allows the kernel to be compiled using the normal steps: make mrproper cp configs/kernel-2.4.22-i686.config .config make oldconfig make dep make bzImage
Comment 10 Need Real Name 2003-12-03 21:45:31 UTC
This problem also affects the i586.config file and possibly others
Comment 11 Josh Boyer 2003-12-05 02:41:54 UTC
it is in all the i*86 UP config files. it is also still in the most recent kernel update that has been released: [root@yoda root]# rpm -qa | grep kernel-source kernel-source-2.4.22-1.2129.nptl [root@yoda root]#
Comment 12 Josh Boyer 2003-12-05 02:44:47 UTC
Created attachment 96363 [details] patch for .config files with this problem for kernel-source-2.4.22-1.2129.ntpl this patch will allow the kernel to be compiled using the normal compilation steps.
Comment 13 Josh Boyer 2003-12-05 02:53:02 UTC
the athlon and x86_64 configs are not affected because CONFIG_NR_SIBLINGS_* are to be related to hyperthreading (see arch/i386/config.in). CONFIG_SMP needs to be set for hyperthreading to work. since CONFIG_SMP is not set for uniprocessor config files, neither should CONFIG_NR_SIBLINGS_2. and hyperthreading probably shouldn't be set by default anyway because only i686 CPUs support this, and not even all of those do.
Comment 14 Darin May 2003-12-14 01:40:44 UTC
Finally found this in bugzilla after trawling through Google. I concur about HypeThreading[tm] as my 2.26GHz P4 does not have it. Will patches be submitted for all Ix86 config files?
Comment 15 Darin May 2003-12-14 17:56:03 UTC
Duh. Finally got down to Josh's complete patch file. Thanks for the solution -- looks like I got a clean compile on the *-i686.config file.
Comment 16 Josh Boyer 2003-12-15 00:11:30 UTC
Welcome. i'll keep posting patches until someone decides to roll the fix into an official RPM... Ingo or Bill, are you listening? ;)
Comment 17 Darin May 2003-12-30 01:45:13 UTC
The latest kernel source doesn't work either( @.2135-1). I'll try to see if your patch works on this distro
Comment 18 Josh Boyer 2004-01-07 13:52:52 UTC
Created attachment 96801 [details] configs patch for kernel-source-2.4.22-1.2138.nptl.i386.rpm patch file for latest kernel-source RPM since the problem wasn't fixed... again. sigh.
Comment 19 Darin May 2004-01-08 00:56:28 UTC
The updated patch (id=96801) is also needed (and works) for the 2140 kernel release.
Comment 20 Darin May 2004-01-08 08:49:43 UTC
How are bugs managed and fixes targeted for release? At least with the mozilla project you can see which release target the fix is aimed at.
Comment 21 Josh Boyer 2004-01-08 16:34:09 UTC
no idea. i noticed Dave Jones has a new kernel in testing... maybe he will be kind enough to fix this bug for us in the kernel-source RPM.
Comment 22 Dave Jones 2004-01-08 16:49:56 UTC
The patch above isn't any use as those files are automatically generated. I've fiddled with the bits the scripts get fed, so hopefully the next update in -testing will have this fixed.
Comment 23 Josh Boyer 2004-01-08 18:32:55 UTC
thanks for the feedback. i take it we don't have access to the scripts that generate the configs (in a SRPM for mabye)? i was hoping the fedora CVS tree would be up and running by now, but no such luck.
Comment 24 Dave Jones 2004-01-09 20:49:50 UTC
*** Bug 112689 has been marked as a duplicate of this bug. ***
Comment 25 Dave Jones 2004-01-09 20:52:20 UTC
We've cleaned the scripts up and changed how they work a little for FC2. With kernels from that release, you'll really get everything.. Hopefully at some point you'll even be able to cvs pull from the same server I commit to, but now we're digressing.. I'll push out another -testing kernel in a few days.
Comment 26 Darin May 2004-01-15 10:00:33 UTC
New kernel release 2149 still needs the patch.
Comment 27 Dave Jones 2004-01-15 15:42:41 UTC
Try 2154 from the testing branch. (2149 was already in testing when I posted my last comment).
Comment 28 Darin May 2004-01-15 16:15:56 UTC
Ah, OK. I've just been getting the up2date rpms as they're released.
Comment 29 Josh Boyer 2004-01-15 17:22:14 UTC
2154 from the testing branch compiles the bzImage and modules correctly (using kernel-2.4.22-i686.config anyway). thanks for the quick response. (cheers go up from the crowd).
Comment 30 Darin May 2004-02-13 10:50:02 UTC
Seems fixed now with 2.4.22-1.2166 kernel source pushed by up2date. The config file patch was not needed to recompile with Pentium 4 selected as the CPU.