[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc & kernel



On Wed, 11 Apr 2001, Jan Gregor wrote:

>  I moved to debian potato last month from redhat 6.1 . I think I found
> bug in gcc which influence kernel. First I used kernel 2.2.18pre21
> from potato. Sometimes after loading from lilo and showing
> "uncompressing linux ... " my computer halts. When I started kernel from 
> loadlin or used old kernel (2.2.16) from redhat this thing never matters.
> Then I moved to kernel 2.2.19 (downloaded as tar.gz from www.kernel.org).
> Everything worked fine until today (two days). Kernel showed after
> uncompressing linux ... and empty line crc error.
>  My computer use cyrix 686 150+ (I think revision 2.6) and board is 
> tomato 5dhx (intel hx chipset).
>  I think problem may be in gcc because redhat use egcs 1.1.2 and it is
> older than gcc 2.95 in redhat. Maybe some problems with cyrix. But I can't
> understand why with loadlin is everything okay and with lilo sometimes not.

There were some issues with some 2.2.x kernels and Cyrix processors,
IIRC.  I'm not even sure if they were resolved yet or not,
unfortunately.  It is very possible that gcc is not generating or
scheduling code correctly for Cyrix, but I'm unsure there as well.  I can
say that, for an Intel CPU (Pentium 1, 2, & 3), I haven't seen any similar
problems on any of my home machines with kernels 2.2.16-2.4.1.

The crc error may also be one of a few things.  I don't know too much
about PC hardware or Linux's error codes on IA32-class systems (I'm mostly
and Alpha person), but from what I do know, it's possible that you have
either a misgenerated kernel or possible some hardware issues with your
RAM.  Having never seen such a message, though, I can't confirm either.

Have you tried recompiling the same kernel source on a RedHat system using
egcs 1.1.2 and booting from that kernel?  I'd be interested to see if the
same source compiled under an older egcs version actually behaved
differently.  Code generation will definitely be different between the
two, as will scheduling and binary size, fyi, but the overall behaviour
should be close to the same.

C



Reply to: