Re: sig 11 problem when compiling kernel???
because you are using K6, make sure that it is made after week 30. K6
before week 30 will trigger a bug where people cannot compile Linux
kernel if there are more than 32MB in their computer. It only happens
to Linux world and in fact the bug is uncovered by Linux guys.
Frank Sergeant wrote:
>
> th@womensports.com (Thalia L. Hooker) wrote
>
> > Anyways, my next step was to 'make zImage'. I kept getting Sig 11 errors
> > though not at the same point of compilation:
> > gcc: Internal compiler error: program cc1 got fatal signal 11
> ...
> > After reading the FAQ, it seemed that my problems were typical of the ones
> > described by other users. I have tried at least 30 times starting over
> > from:
> > make dep ; make clean
> > make zImage
> >
> > So, has any one had the same thing happen to them and did it turn out to be
> > a RAM problem? Or, how were you able to solve it?
>
> I seem to have (nearly) the same problem on my AMD K90 system,
> except the error I usually get is "segmentation fault". Again, it
> happens at random places during a kernel compile. (I delete the
> last .obj file and restart the compile with 'make zImage' and the
> compile continues. Eventually, I make it all the way through with
> a successful compile.) I also run into it perhaps 1 out of 3 times
> when I do a large LaTeX compile, again at random places in the
> compile.
>
> I am inclined to believe that the sig 11 and the segmentation
> faults are indeed symptoms of bad hardware. Last May, I spent
> several days swapping RAM SIMMs around, hoping to get a good
> set that would cure the kernel compile symptom, but with no
> luck. I have tentatively concluded that my problem is not
> bad RAM but some other hardware problem. My next step, when
> I have the strength to face it, is to pull all the non-essential
> cards and try again. I also have a few additional SIMMs to
> try, just in case all the others I tried were bad. If pulling
> the cards doesn't solve it, I will see if I can jump the
> motherboard to reduce the CPU clock speed and/or bus speed.
> I already tried turning off the CPU and motherboard caches,
> without that solving it.
>
> This really is a fascinating topic, I think. How can
> we (at least I) get any work done when I don't have full
> confidence in my working platform? Well, on this same
> machine, W95 (often) and plain DOS (sometimes) lock up
> on me. I spend more time in Linux, though, and it
> essentially never locks up on me, but does bomb out on
> kernel or LaTeX compiles. At least under Linux, the
> error is caught gracefully and I continue to have a command
> prompt and working operating system, whereas W95 is
> extremely rude in requiring the machine to be powered off.
> So, I would say, from my experience on this one machine,
> that, given the same level of faulty hardware, Linux is
> much more reliable.
>
> Now, another interesting point: if indeed the problems
> I've experienced on this machine are really _hardware_
> problems, and even though W95 cannot cope with those
> failures gracefully, is it possible that W95 runs
> reliably given flawless hardware? That is, is it possible
> that W95 gets a worse reputation than it deserves due
> to unsuspected bad hardware? Perhaps I will take to
> recommending that customers purchase only Hewlett-Packward
> PCs. Would that solve it? (At least, Hewlett-Packward
> seems to have a good reputation for quality hardware.)
>
> -- Frank
> frank.sergeant@pobox.com
>
> --
> TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
> debian-user-request@lists.debian.org .
> Trouble? e-mail to templin@bucknell.edu .
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: