OOPS: ext3/sparc badness

OOPS: ext3/sparc badness

[Beezly]

I'm having problems with an ext3 filesystem on sparc64 (an Ultra1).

kernel is: 

Linux lemur 2.4.19-pre7 #5 SMP Fri Apr 26 01:30:49 BST 2002 sparc64
unknown

and was compiled with gcc-3.0.4.

The ext3 filesystem is on an md-raid1 set and I get an oops after a
seemingly random amount of time. The kernel was compiled with gcc-3.0.4
because it appears 2.95 does not compile the md code correctly on Sparc
(see http://marc.theaimsgroup.com/?l=linux-raid&m=101981888804890&w=2). 
Here's the oops. I would be very happy to help debugging this problem.

Cheers,

Andrew Beresford

Oops follows...

Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 000000000000070e
tsk->{mm,active_mm}->pgd = fffff8000155e000
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
mrtg(14342): Oops
CPU[0]: local_irq_count[0] irqs_running[0]
TSTATE: 0000004411009607 TPC: 00000000004a2b3c TNPC: 00000000004a2b40 Y: 00000000    Not tainted
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: fffff8000074bb78 g1: 00000000004a2960 g2: 0000000000000001 g3: fffff800115cd068
g4: fffff80000000000 g5: 0000000000000001 g6: fffff80001564000 g7: 0000000000000001
o0: fffff80001564000 o1: 0000000000000000 o2: 0000000000ff0000 o3: 000000000000ff00
o4: 0000000000000001 o5: 0000000000000001 sp: fffff800015672c1 ret_pc: 00000000004a2b20
l0: fffff800104f0400 l1: fffff8001257fd20 l2: 00000000006d1800 l3: fffff80013e913b0
l4: 000000000000000a l5: fffff80003e0a011 l6: 00000000005f9400 l7: 0000000000649c00
i0: fffffffffffffff3 i1: fffff800104f0400 i2: 00000000005fad40 i3: 00000000004a2b00
i4: 0000000000000005 i5: 0000000000000003 i6: fffff80001567391 i7: 00000000004784d0
Caller[00000000004784d0]
Caller[000000000047904c]
Caller[00000000004799ec]
Caller[00000000004751d0]
Caller[00000000004112f4]
Caller[00000000702b5040]
Instruction DUMP: 94102000  15003fc0  d25fa7e7 <d6024000> 1300003f  a12ae018  92126300  920ac009  940ac00a 


>>PC;  004a2b3c <ext3_lookup+3c/c0>   <=====

>>g0; fffff8000074bb78 <END_OF_CODE+fffff7fffe748eb5/????>
>>g1; 004a2960 <ext3_find_entry+1a0/340>
>>g3; fffff800115cd068 <END_OF_CODE+fffff8000f5ca3a5/????>
>>g4; fffff80000000000 <END_OF_CODE+fffff7fffdffd33d/????>
>>g6; fffff80001564000 <END_OF_CODE+fffff7ffff56133d/????>
>>o0; fffff80001564000 <END_OF_CODE+fffff7ffff56133d/????>
>>o2; 00ff0000 <_end+8b44f8/18c44f8>
>>o3; 0000ff00 Before first symbol
>>sp; fffff800015672c1 <END_OF_CODE+fffff7ffff5645fe/????>
>>ret_pc; 004a2b20 <ext3_lookup+20/c0>
>>l0; fffff800104f0400 <END_OF_CODE+fffff8000e4ed73d/????>
>>l1; fffff8001257fd20 <END_OF_CODE+fffff8001057d05d/????>
>>l2; 006d1800 <cdev_hashtable+370/400>
>>l3; fffff80013e913b0 <END_OF_CODE+fffff80011e8e6ed/????>
>>l5; fffff80003e0a011 <END_OF_CODE+fffff80001e0734e/????>
>>l6; 005f9400 <rdwr_pipe_fops+80/90>
>>l7; 00649c00 <dcache_lock+0/40>
>>i0; fffffffffffffff3 <END_OF_CODE+fffffffffdffd330/????>
>>i1; fffff800104f0400 <END_OF_CODE+fffff8000e4ed73d/????>
>>i2; 005fad40 <ext3_dir_inode_operations+0/80>
>>i3; 004a2b00 <ext3_lookup+0/c0>
>>i6; fffff80001567391 <END_OF_CODE+fffff7ffff5646ce/????>
>>i7; 004784d0 <real_lookup+f0/1a0>

Trace; 004784d0 <real_lookup+f0/1a0>
Trace; 0047904c <link_path_walk+90c/c20>
Trace; 004799ec <__user_walk+4c/80>
Trace; 004751d0 <sys_stat64+10/a0>
Trace; 004112f4 <linux_sparc_syscall32+34/40>
Trace; 702b5040 <END_OF_CODE+6e2b237d/????>

Code;  004a2b30 <ext3_lookup+30/c0>
00000000 <_PC>:
Code;  004a2b30 <ext3_lookup+30/c0>
   0:   94 10 20 00       clr  %o2
Code;  004a2b34 <ext3_lookup+34/c0>
   4:   15 00 3f c0       sethi  %hi(0xff0000), %o2
Code;  004a2b38 <ext3_lookup+38/c0>
   8:   d2 5f a7 e7       unknown
Code;  004a2b3c <ext3_lookup+3c/c0>   <=====
   c:   d6 02 40 00       ld  [ %o1 ], %o3   <=====
Code;  004a2b40 <ext3_lookup+40/c0>
  10:   13 00 00 3f       sethi  %hi(0xfc00), %o1
Code;  004a2b44 <ext3_lookup+44/c0>
  14:   a1 2a e0 18       sll  %o3, 0x18, %l0
Code;  004a2b48 <ext3_lookup+48/c0>
  18:   92 12 63 00       or  %o1, 0x300, %o1
Code;  004a2b4c <ext3_lookup+4c/c0>
  1c:   92 0a c0 09       and  %o3, %o1, %o1
Code;  004a2b50 <ext3_lookup+50/c0>
  20:   94 0a c0 0a       and  %o3, %o2, %o2


1 warning issued.  Results may not be reliable.

Re: OOPS: ext3/sparc badness

[Beezly]

Talking to myself :), but...

On Mon, 2002-05-20 at 13:32, Beezly wrote:
> o0: fffff80001564000 o1: 0000000000000000 o2: 0000000000ff0000 o3: 000000000000ff00

> Code;  004a2b30 <ext3_lookup+30/c0>
> 00000000 <_PC>:
> Code;  004a2b30 <ext3_lookup+30/c0>
>    0:   94 10 20 00       clr  %o2
> Code;  004a2b34 <ext3_lookup+34/c0>
>    4:   15 00 3f c0       sethi  %hi(0xff0000), %o2
> Code;  004a2b38 <ext3_lookup+38/c0>
>    8:   d2 5f a7 e7       unknown

This is:

	ldx [%fp+0x7e7],%o1

> Code;  004a2b3c <ext3_lookup+3c/c0>   <=====
>    c:   d6 02 40 00       ld  [ %o1 ], %o3   <=====

gdb says;

Dump of assembler code for function ext3_lookup:
0x4a2b00 <ext3_lookup>:	save  %sp, -208, %sp
0x4a2b04 <ext3_lookup+4>:	mov  %i0, %l1
0x4a2b08 <ext3_lookup+8>:	add  %fp, 0x7e7, %o1
0x4a2b0c <ext3_lookup+12>:	ld  [ %i1 + 0x78 ], %o2
0x4a2b10 <ext3_lookup+16>:	mov  %i1, %o0
0x4a2b14 <ext3_lookup+20>:	cmp  %o2, 0xff
0x4a2b18 <ext3_lookup+24>:	bgu  %icc, 0x4a2bac <ext3_lookup+172>
0x4a2b1c <ext3_lookup+28>:	mov  -63, %i0
0x4a2b20 <ext3_lookup+32>:	call  0x4a27c0 <ext3_find_entry>
0x4a2b24 <ext3_lookup+36>:	mov  -13, %i0
0x4a2b28 <ext3_lookup+40>:	mov  %o0, %o1
0x4a2b2c <ext3_lookup+44>:	brz,pn   %o1, 0x4a2b94 <ext3_lookup+148>
0x4a2b30 <ext3_lookup+48>:	clr  %o2
0x4a2b34 <ext3_lookup+52>:	sethi  %hi(0xff0000), %o2
0x4a2b38 <ext3_lookup+56>:	ldx  [ %fp + 0x7e7 ], %o1
0x4a2b3c <ext3_lookup+60>:	ld  [ %o1 ], %o3
0x4a2b40 <ext3_lookup+64>:	sethi  %hi(0xfc00), %o1
0x4a2b44 <ext3_lookup+68>:	sll  %o3, 0x18, %l0

we are trying to load **res_dir for ext3_find_entry. Unfortunately, it appears that either *res_dir, or **res_dir is 0 (as %o1 ends up being 0's):( 

Beezly

Re: OOPS: ext3/sparc badness

[David S. Miller]

   From: Beezly <beezly@beezly.org.uk>
   Date: 20 May 2002 13:32:00 +0100

   I'm having problems with an ext3 filesystem on sparc64 (an Ultra1).
   
   kernel is: 
   
   Linux lemur 2.4.19-pre7 #5 SMP Fri Apr 26 01:30:49 BST 2002 sparc64
   unknown
   
   and was compiled with gcc-3.0.4.
   
Unsupported compiler for sparc64 kernels.  Your OOPS report is going
to be ignored.

Re: OOPS: ext3/sparc badness

[Christoph Hellwig]

On Mon, May 20, 2002 at 02:30:18PM -0700, David S. Miller wrote:
> Unsupported compiler for sparc64 kernels.  Your OOPS report is going
> to be ignored.

Btw, is gcc 3.1 supported now or only the magic egcs variant?

Re: OOPS: ext3/sparc badness

[David S. Miller]

   From: Christoph Hellwig <hch@infradead.org>
   Date: Mon, 20 May 2002 22:52:06 +0100

   On Mon, May 20, 2002 at 02:30:18PM -0700, David S. Miller wrote:
   > Unsupported compiler for sparc64 kernels.  Your OOPS report is going
   > to be ignored.
   
   Btw, is gcc 3.1 supported now or only the magic egcs variant?
   
gcc-3.1 should work properly, I've used it but I'm hesitant to %100
bless it just yet. :-)

I would prefer to receive bug reports only against the sparc64-egcs
compiler still.

Re: OOPS: ext3/sparc badness

[David S. Miller]

   From: Andrew Beresford <beezly@beezly.org.uk>
   Date: Tue, 21 May 2002 09:30:04 +0100
   
   Understood, but the reason I was using 3.0.4 was because sparc64-egcs
   has been suspected of generating some bad code in the md.c (see the link
   in the previous e-mail I sent).

I don't think so... but please repost the link as I've deleted all of
your emails.

Re: OOPS: ext3/sparc badness

[Andrew Beresford]

David,

On Mon, May 20, 2002 at 03:06:28PM -0700, David S. Miller wrote:
>    From: Christoph Hellwig <hch@infradead.org>
>    Date: Mon, 20 May 2002 22:52:06 +0100
> 
>    On Mon, May 20, 2002 at 02:30:18PM -0700, David S. Miller wrote:
>    > Unsupported compiler for sparc64 kernels.  Your OOPS report is going
>    > to be ignored.

Understood, but the reason I was using 3.0.4 was because sparc64-egcs
has been suspected of generating some bad code in the md.c (see the link
in the previous e-mail I sent).

>    Btw, is gcc 3.1 supported now or only the magic egcs variant?
>    
> gcc-3.1 should work properly, I've used it but I'm hesitant to %100
> bless it just yet. :-)
> 
> I would prefer to receive bug reports only against the sparc64-egcs
> compiler still.

I will give gcc-3.1 a try.

Cheers,

Beezly

Re: OOPS: ext3/sparc badness

[David S. Miller]

   From: Andrew Beresford <beezly@beezly.org.uk>
   Date: Tue, 21 May 2002 09:38:05 +0100

   The link is;
   
   http://marc.theaimsgroup.com/?l=linux-raid&m=101981888804890&w=2
   
Ok, we need to find some workaround at least for 2.4.x as this
is the compiler most people on sparc64 are using.

I'll play with it a bit...

Re: OOPS: ext3/sparc badness

[Andrew Beresford]

Hi David,

On Tue, May 21, 2002 at 01:18:58AM -0700, David S. Miller wrote:
> I don't think so... but please repost the link as I've deleted all of
> your emails.

The link is;

http://marc.theaimsgroup.com/?l=linux-raid&m=101981888804890&w=2

Cheers,

Beezly

Re: OOPS: ext3/sparc badness

[Andrew Beresford]

Hi David,

On Tue, May 21, 2002 at 01:34:44AM -0700, David S. Miller wrote:
> Ok, we need to find some workaround at least for 2.4.x as this
> is the compiler most people on sparc64 are using.
> 
> I'll play with it a bit...

Great :) Please let me know if I can help with anything.

Cheers,

Beezly

Re: OOPS: ext3/sparc badness

[David S. Miller]

   From: Andrew Beresford <beezly@beezly.org.uk>
   Date: Tue, 21 May 2002 09:38:05 +0100

   On Tue, May 21, 2002 at 01:18:58AM -0700, David S. Miller wrote:
   > I don't think so... but please repost the link as I've deleted all of
   > your emails.
   
   The link is;
   
   http://marc.theaimsgroup.com/?l=linux-raid&m=101981888804890&w=2

To recap, the compiler used to build sparc64 kernels miscompiles
drivers/md/raid1.c:raid1_read_balance()

The following appears to be a good workaround for this
bug, Neil could you put this into your tree and would you
mind if I sent this to Marcelo for 2.4.20-preX?

--- drivers/md/raid1.c.~1~	Fri Aug 30 17:03:02 2002
+++ drivers/md/raid1.c	Fri Aug 30 17:17:46 2002
@@ -23,6 +23,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/config.h>
 #include <linux/slab.h>
 #include <linux/raid/raid1.h>
 #include <asm/atomic.h>
@@ -522,6 +523,10 @@
 	if (conf->sect_count >= conf->mirrors[new_disk].sect_limit) {
 		conf->sect_count = 0;
 
+#if defined(CONFIG_SPARC64) && (__GNUC__ == 2) && (__GNUC_MINOR__ == 92)
+		/* Work around a compiler bug in egcs-2.92.11 19980921 */
+		new_disk = *(volatile int *)&new_disk;
+#endif
 		do {
 			if (new_disk<=0)
 				new_disk = conf->raid_disks;