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!
Does this persist with 2.4.22-1.2075?
Yes, it still reproduces in 2.4.22-1.2081
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.
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[3]: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/nls' make[2]: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/nls' make -C partitions make[2]: Entering directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/partitions' make all_targets make[3]: 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[2]: *** [first_rule] Segmentation fault make[2]: Leaving directory `/usr/src/linux-2.4.22-1.2097.nptl/fs/partitions' make[1]: *** [_subdir_partitions] Error 2 make[1]: 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[1]: *** [i8259.o] Error 1 make[1]: 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
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.
Sorry above comments should be for Edward not Behdad :(
*** Bug 109540 has been marked as a duplicate of this bug. ***
The gcc32 'workaround' mentioned above is bogus. This bug is still there, and only goes away when you do make oldconfig twice.
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
This problem also affects the i586.config file and possibly others
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]#
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.
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.
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?
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.
Welcome. i'll keep posting patches until someone decides to roll the fix into an official RPM... Ingo or Bill, are you listening? ;)
The latest kernel source doesn't work either( @.2135-1). I'll try to see if your patch works on this distro
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.
The updated patch (id=96801) is also needed (and works) for the 2140 kernel release.
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.
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.
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.
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.
*** Bug 112689 has been marked as a duplicate of this bug. ***
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.
New kernel release 2149 still needs the patch.
Try 2154 from the testing branch. (2149 was already in testing when I posted my last comment).
Ah, OK. I've just been getting the up2date rpms as they're released.
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).
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.