gcc versions used to compile a kernel

The last days I had a lot of trouble getting different kernel versions to run. Enclosed is a short report of the experience I made.

First I tried to compile all kernels with gcc 3.3.1.

2.4.20 I even couldn't compile.
2.4.22-ac4 compiled well but oopsed immediately after booting. 2.6.0-test4 and test5 compiled well but didn't boot and froze with a blank screen.
2.6.0-test6 compiled well but froze after starting /sbin/init.

Then I used gcc 2.95.3 for compiling 2.4.20, 2.4.22-ac4 and 2.6.0- test7 and all kernels booted smoothly.

It's seems that at least in my configuration gcc 3.3.1 is doing a bad job.

Mit freundlichen Gruessen/Best regards,
Sebastian Piecha

EMail: [email protected]

Well maybe for x86.
On alpha, as i described in this list, i got an oops in raid1.c for kernel 2.4.17..21, 2.6.0-test7 with gcc-2.95.3, gcc-3.3 (3.4 is in work by me).
It seems that´t this a problem with gcc and option -O2. With optimizing set to -O0 everything is ok. So i think gcc gives bad assembler code.
BUT: This problem still exists until now - latest kernel, latest stable gcc. Redhat have had a patch for this since RH 7.1 with gcc 2.26. The problem is still there!! OK, why change the kernel code in raid1.c read_balance, if it´s a fault in gcc. And we use gcc 2.95-3, gcc 3.2.2 ( i don´t test it, but i think 3.3 or 3.3.1 is newer and contains fixes for 3.2.2 ..) and we got still this very old, well known bug in raid1.c:read_balance() on alpha.

What to do? Everytime patch the raid1.c?

Unable to handle kernel paging request at virtual address 0000000000000059
swapper(1): Oops 0
pc = [<fffffc000050dd50>]  ra = [<fffffc000050e200>]  ps = 0007    Not tainted
v0 = 0000000000000000  t0 = 0000000000000002  t1 = 0000000000000001
t2 = 0000000000000000  t3 = fffffc000015d6e8  t4 = 0000000000000001
t5 = fffffc0000182c50  t6 = 0000000000000002  t7 = fffffc0000c24000
s0 = fffffc001fcad408  s1 = fffffc00001b26e0  s2 = 0000000000000002
s3 = fffffc0000182c50  s4 = fffffc00010d5f68  s5 = 0000000000000002
s6 = fffffc0000105148
a0 = 0000000000000007  a1 = fffffc00010d5f68  a2 = fffffc001fcad408
a3 = 0000000000000400  a4 = 0000000000000018  a5 = 0000000000000000
t8 = 0000000000000000  t9 = fffffc000015d6f8  t10= 0000000000000004
t11= 0000000000000001  pv = fffffc000043ba20  at = 0000000000000002
gp = fffffc00006df608  sp = fffffc0000c27b18

Trace:fffffc0000482c80 fffffc0000329320 fffffc0000482d68 fffffc000037a2c8 fffffc0000377340 fffffc00003 77784 fffffc00003d05ec fffffc000037da10 fffffc00003d04a0 fffffc00003d275c fffffc000035646d fffffc00003 7de58 fffffc000039a6a8 fffffc000039ab1c fffffc000039afb8 fffffc000039af94 fffffc0000310000 fffffc00003 101ac fffffc00003135b8

Code: a0a60010  47ff041f  40821524  40a03125  a4440000  e440000e <a0220058> e420000c

Trace; fffffc0000482c80 <generic_make_request+220/260> Trace; fffffc0000329320 <autoremove_wake_function+0/60> Trace; fffffc0000482d68 <submit_bio+a8/c0> Trace; fffffc000037a2c8 <submit_bh+1a8/1e0> Trace; fffffc0000377340 <__bread_slow+a0/100> Trace; fffffc0000377784 <__bread+24/40>
Trace; fffffc00003d05ec <ext3_fill_super+14c/f60> Trace; fffffc000037da10 <get_sb_bdev+170/240> Trace; fffffc00003d04a0 <ext3_fill_super+0/f60> Trace; fffffc00003d275c <ext3_get_sb+1c/60> Trace; fffffc000035646d <cache_alloc_refill+40d/5c0> Trace; fffffc000037de58 <do_kern_mount+98/220> Trace; fffffc000039a6a8 <do_add_mount+a8/220> Trace; fffffc000039ab1c <do_mount+1dc/220> Trace; fffffc000039afb8 <sys_mount+b8/160> Trace; fffffc000039af94 <sys_mount+94/160> Trace; fffffc0000310000 <_text+0/0>
Trace; fffffc00003101ac <init+2c/100>
Trace; fffffc00003135b8 <kernel_thread+28/90>

Code; fffffc000050dd38 <read_balance+158/280>
0000000000000000 <_PC>:
Code; fffffc000050dd38 <read_balance+158/280>
0: 10 00 a6 a0 ldl t4,16(t5)
Code; fffffc000050dd3c <read_balance+15c/280>
4: 1f 04 ff 47 nop
Code; fffffc000050dd40 <read_balance+160/280>
8: 24 15 82 40 subq t3,0x10,t3
Code; fffffc000050dd44 <read_balance+164/280>
c: 25 31 a0 40 subl t4,0x1,t4
Code; fffffc000050dd48 <read_balance+168/280>
10: 00 00 44 a4 ldq t1,0(t3)
Code; fffffc000050dd4c <read_balance+16c/280>
14: 0e 00 40 e4 beq t1,50 <_PC+0x50> fffffc000050dd88 <read_balance+1a8/280>
Code; fffffc000050dd50 <read_balance+170/280> <=====
18: 58 00 22 a0 ldl t0,88(t1) <=====
Code; fffffc000050dd54 <read_balance+174/280>
1c: 0c 00 20 e4 beq t0,50 <_PC+0x50> fffffc000050dd88 <read_balance+1a8/280>

From raid1.c:
if (!conf->mirrors[disk].rdev ||

                    !conf->mirrors[disk].rdev->in_sync)
                        continue;

Kernel panic: Attempted to kill init!

Tom

LINUX user since kernel 0.99.x 1994.
RPM Alpha packages at http://alpha.steudten.com/packages




-
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

It seems like the fix was accidentally not committed for the 3.3 branch (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11087). I hope we can still include it for the upcoming 3.3.2 release.

	Falk

Dear Sebastian,

This is very interesting as I've been compiling kernels with GCC 3.2.0 and higher since the first beta I compiled. I've never had the issues that you are describing with kernel 2.5.70 and higher and 2.6.0 test 1> 6. This most likly is a machine related problem. Which Linux distibution are you using and how uptodate is the rest of the machine.

Best regards,

Stef

I'm using a SuSE 8.20 distribution (kernel 2.4.20). The system is regularly updated with SuSE online update. The only things I changed are:
mdadm v1.3.0
gcc 2.95.3

Mit freundlichen Gruessen/Best regards,
Sebastian Piecha

EMail: [email protected]