public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Steudten <alpha@steudten.com>
To: linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org
Subject: Re: raid1.c and gcc problem/oops (was: [INFO] gcc versions used to compile a kernel
Date: Mon, 13 Oct 2003 16:41:45 +0200	[thread overview]
Message-ID: <3F8AB9A9.9010502@steudten.com> (raw)
In-Reply-To: <3F8ACFA0.10239.10815846@localhost>

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

>>RA;  fffffc000050e200 <make_request+e0/3c0>

>>PC;  fffffc000050dd50 <read_balance+170/280>   <=====

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!


Sebastian Piecha wrote:

> 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.

> 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.
>
-- 
Tom

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





  reply	other threads:[~2003-10-13 14:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-13 14:15 [INFO] gcc versions used to compile a kernel Sebastian Piecha
2003-10-13 14:41 ` Thomas Steudten [this message]
2003-10-13 15:12   ` raid1.c and gcc problem/oops (was: " Falk Hueffner
2003-10-13 19:50 ` Stef van der Made
2003-10-13 22:20   ` Sebastian Piecha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F8AB9A9.9010502@steudten.com \
    --to=alpha@steudten.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox