problems compiling kernel

I am attempting to recompile the 2.2.14 kernel.  I have successfully compiled this kernel before and am currently using that version.  I am recompiling to change a few configuration options.

Now, though, I can't get all the way through.  I get errors like:

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=586   -c -o panic.o panic.c
gcc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [panic.o] Error 1
make[2]: Leaving directory `/usr/src/linux/kernel'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/kernel'
make: *** [_dir_kernel] Error 2
/usr/src/linux>



It is not always on the same file - in fact, every time it seems to be on a different file.  And if I run 'make bzImage' again right away, it will be able to compile that file.  It will continue on past that point and have the same error on another file.  Eventually, however, it seems to get to a point that it can't get past.

I used 'make menuconfig' to setup the options, followed by 'make clean' and 'make dep' before finally typing 'make bzImage'

Any help would be appreciated.
red5Asked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
freesourceConnect With a Mentor Commented:
O.k., assuming your cache is still off, I'd try to narrow things down.  You can try different memory or try booting
with mem=4M.  This is all mentioned under the question "What do I do".

The K6 thing probably doesn't apply because this was mostly related to K6-2's of a certain version.  

If things were working fine before with this same hardware setup .. and you haven't changed anything .. then something somewhere is starting to break down.

Try doing something else which uses a lot of memory and see if the kernel complains, and look at your logs, too.
Be careful, because bad memory can cause bad problems with the ext2 filesystem.

On the other hand, even dust build-up has been known to cause sig11 problems.
0
 
fmartin092599Commented:
are you running lilo when you are finished.
A shortcut is make bzlilo instead of make bzImage
0
 
jlevieCommented:
What version of gcc are you using (gcc -c)? How much memeory do you have and how much swap space?
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
friebeleCommented:
You said that it compiled before. Did you "make clean" before attempting it this time. When compiling residual files are left over in the src directory and the next time you attempt to compile it may not operate properly.
0
 
freesourceCommented:
Here is the first clue:

got fatal signal 11

The second clue is this:

"it is not always on the same file - in fact, every time it seems to be on a different file"

The best place to read about this problem is here:

http://www.bitwizard.nl/sig11/

I had this very same problem once after I installed new memory.  My solution was to get new memory from a different manufacturer.  Your solution may be something else.  But "The Sig11 FAQ " is very revealing and should solve your problem.
0
 
mapcCommented:
This is an answer:
Because your system runs stably (I suppose) this is not a RAM problem (or maybe it is).
And since it happends when you compile kernel - cpu intensive task, I can bet that it's your CPU.
Either you have overclocked it not wisely, or, I guess that your cpu fan has died.
Exactly the same results were observed when one of our production machines had CPU fan that died.
Other then that: adding new disks to the case raise temperature, this is a problem in "thin" machines, pizzaboxes like sparcs, haven't seen this problem on pcs though.
Hope that it helps, take care
0
 
freesourceCommented:
Indeed, and the FAQ I mentioned covers the things mpac mentioned along with many other causes :)  The point is "signal 11" can have a large variety of causes, but they are generally hardware related .. but not always .. this is covered in the FAQ as well.

I am 100% positive you will find a solution in this FAQ.

Sometimes these problems can get very nasty if not fixed early .. so I hope you solve your problem soon.
0
 
red5Author Commented:
I am rejecting this answer for now to invite more comments.

Here is some info about my system.

I have the Tyan S1590 motherboard. It had some bad cache that was causing my system to lock up before, so I have the cache turned off.

I am using an AMD K6-3 400.  I can't determine if this would have the same K6 bug mentioned in that web page.

I have 128MB of RAM (PC-100) and haven't noticed any other problems with that, but may not have stressed it enough either.
0
 
red5Author Commented:
More info -

I am not overclocking my CPU.  I have a temperature gauge in the case that usually reads ~90 deg F.  The motherboard also has a temperature gauge on the CPU and I'll have to check to see what it's runs at.  (unfortuneately I have to go back to the BIOS to read it and by then it may have cooled slightly)
0
 
billwccCommented:
with respect to fmartin, you may wish
to avoid make zlilo or bzlilo as this will install your new kernel as the one lilo invokes when it boots up.

if your new kernel is not right, you'll be stuck with it and have to boot from
floppy.  suggest you use (b)zlilo only with perfected kernels.

v/r, Bill Cunningham
0
 
mixerfix122699Commented:
I suspect that something choked on the motherboard.. Either memory or CPU.

A much less like possibility is the C compiler itself, but it is a distant second.
0
 
mapcCommented:
do us a favor, open the case and see if the fan is working. lmmon may be wrong btw.
0
 
bcwhiteCommented:
It's amazing how GCC will find problems with memory that doesn't affect anything else.  Still, if you get a signal-11 from GCC, it's almost certainly an memory problem.

-- Brian
0
 
ReinierCommented:
You can check your memory with memtest86:  http://reality.sgi.com/cbrady_denver/memtest86/

Hope it helps.
0
 
red5Author Commented:
Well, memtest86 is an awesome program.  Using it, I discovered a bad bit at 0x05603218 which I think would put that in my second 64MB SIMM.  Guess I'll have to replace it.  I'm guessing this is what was causing the gcc failures (yes the cpu fan is running)

I would like to give Reinier some points for that one, but I think freesource's comments also are informative and required a little more effort.

If it were easy to distribute points to multiple experts (which I think is a badly needed feature of this website) I would reward Reinier and freesource, but as it is, I give them to freesource.

Thanks everyone.
0
 
red5Author Commented:
An additional comment:

I removed the bad SIMM, let memtest86 do 3 passes of all tests on the remaining SIMM, got no errors, and was then still unable to recompile the kernel.  Yikes.  Guess I still have some problems.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.