Bug 105978

Summary: Fedora 0.94 test2 kernel does not compile with default config
Product: [Fedora] Fedora Reporter: Ben Hsu <benhsu>
Component: kernelAssignee: Ingo Molnar <mingo>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: behdad, davej, esimmonds, hancockrwd, jwboyer, lohphat, yousefourabi
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-05-26 14:13:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
patch for configs/kernel-2.4.22-i686.config
patch for .config files with this problem for kernel-source-2.4.22-1.2129.ntpl
configs patch for kernel-source-2.4.22-1.2138.nptl.i386.rpm none

Description Ben Hsu 2003-09-30 03:38:36 UTC
Version-Release number of selected component (if applicable):

How reproducible:

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

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

# rpm -qa | grep gcc

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

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

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.