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
