sparc32 smp

sparc32 smp

[Raymond Burns]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 638 bytes --]

Hi

The attached oops occurs during boot when the cache is converted from
static to allocated cache ( kmem_cache_create() )

The attached patch might be a work around until mainline kernel slab
code does something

The occurance in kmem_cache_destroy() is a best guess, my boot hasn't
made it far enough to test it.

static cache is initialized prior to smp_init, the boot cpu is the
only one running. There is no mechanism to initialize numa style cache
heads per smp cpu (that I found). after the memcpy, accessing the
array list_lock for cpu 2 causes the oops.

This got me past the slab stuff into the sunzilog oops ...

Thanx
  Ray


[-- Attachment #2: oops --]
[-- Type: TEXT/PLAIN, Size: 1165 bytes --]

Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = ffffffff
tsk->{mm,active_mm}->pgd = fc000000
swapper(1): Oops [#1]
PSR: 40800fc5 PC: f01e00a4 NPC: f01e00a8 Y: 00000000    Not tainted
PC: <_spin_lock_irq+0x14/0x28>
%G: 00000003 f0021510  40800fe6 00000001  00000007 00656c00  f0d0e000 000000ff
%O: 408000e6 00000001  00000001 00000000  f02094d4 00000000  f0d0fc70 f01e009c
RPC: <_spin_lock_irq+0xc/0x28>
%L: 00000002 f0106044  f0106254 00000001  00000002 00000000  00007fff 0000007f
%I: 00000024 f02094d4  00000001 00000001  f010f74c ffff8c4b  f0d0fcd8 f007a75c
Caller[f007a75c]: do_tune_cpucache+0xe0/0x1ac
Caller[f007a890]: enable_cpucache+0x68/0x90
Caller[f0078f84]: kmem_cache_create+0x2ac/0x3b0
Caller[f025622c]: free_area_init+0x20/0x30
Caller[f0245224]: sun4m_init+0xb0/0x328
Caller[f0014104]: init+0x60/0x19c
Caller[f00195bc]: kernel_thread+0x3c/0x50
Caller[f001401c]: rest_init+0x18/0x34
Caller[f02451b4]: sun4m_init+0x40/0x328
Caller[f02447c8]: _etext+0x642c4/0x64af4
Caller[00000000]: 0x8
Instruction DUMP: 9de3bf98  7ff8dbe9  01000000 <c46e0000> 8090a000  328000c9  c4
0e0000  01000000  81c7e008


[-- Attachment #3: patch --]
[-- Type: TEXT/PLAIN, Size: 908 bytes --]

diff --git a/mm/slab.c b/mm/slab.c
index 85c2e03..f70cb11 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2398,7 +2398,7 @@ int kmem_cache_destroy(struct kmem_cache
 	if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU))
 		synchronize_rcu();
 
-	for_each_online_cpu(i)
+	for_each_online_node(i)
 	    kfree(cachep->array[i]);
 
 	/* NUMA: free the list3 structures */
@@ -3597,7 +3597,7 @@ static int do_tune_cpucache(struct kmem_
 	int i, err;
 
 	memset(&new.new, 0, sizeof(new.new));
-	for_each_online_cpu(i) {
+	for_each_online_node(i) {
 		new.new[i] = alloc_arraycache(cpu_to_node(i), limit,
 						batchcount);
 		if (!new.new[i]) {
@@ -3615,7 +3615,7 @@ static int do_tune_cpucache(struct kmem_
 	cachep->limit = limit;
 	cachep->shared = shared;
 
-	for_each_online_cpu(i) {
+	for_each_online_node(i) {
 		struct array_cache *ccold = new.new[i];
 		if (!ccold)
 			continue;

Re: sparc32 smp

[David Miller]

From: Raymond Burns <rayburns@comcast.net>
Date: Thu, 13 Jul 2006 03:41:25 -0700 (PDT)

> The attached oops occurs during boot when the cache is converted from
> static to allocated cache ( kmem_cache_create() )
> 
> The attached patch might be a work around until mainline kernel slab
> code does something
> 
> The occurance in kmem_cache_destroy() is a best guess, my boot hasn't
> made it far enough to test it.
> 
> static cache is initialized prior to smp_init, the boot cpu is the
> only one running. There is no mechanism to initialize numa style cache
> heads per smp cpu (that I found). after the memcpy, accessing the
> array list_lock for cpu 2 causes the oops.
> 
> This got me past the slab stuff into the sunzilog oops ...

I don't think this patch is right.  It wants to iterate over
online cpus, not online NUMA nodes.  Since CONFIG_NUMA is
not enabled in sparc builds, what you've changed it to do
is simply iterate over cpu "0".

Something else is afoot here.  Perhaps the cpu maps or similar
are not setup early enough.  But if that was the case, Bob
would be seeing this problem on his smp sparc32 machines too.

Sparc32 SMP

[BERTRAND Joël]

	Hello Bob,

	I'm testing some configurations with 2.6.18.2 linux kernel. This kernel 
boots wihtout any trouble and I believe that all troubles we have seen 
are fixed.

	With SuperSparc-II, kernel seems to be stable, but I'm not able to 
untar a linux kernel without receive "tâche interrompue" (unterrupted 
task) or an Oops :

Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 00005058
tsk->{mm,active_mm}->pgd = fc12d000
               \|/ ____ \|/
               "@'/ ,. \`@"
               /_| \__/ |_\
                  \__U_/
tar(13387): Oops [#1]
PSR: 400000c2 PC: f008bd8c NPC: f008bd90 Y: 00000000    Not tainted
PC: <pipe_readv+0xac/0x440>
%G: 00001000 fbbfea14  0000003c 00000030  fbbfea00 73635f6c  f93be000 
00000000
%O: f0a0d900 f0a0d900  fcffb000 63616368  6536345f 70616765  f93bfd88 
f008c030
RPC: <pipe_readv+0x350/0x440>
%L: 00000000 00000000  fbbfea50 fbbfea00  00000000 fcffc000  00000001 
00000001
%I: f93bfe60 00000003  f93bfe60 00001800  fcffb000 00000000  f93bfe00 
f008c140
Caller[f008c140]: pipe_read+0x20/0x28
Caller[f007dee8]: vfs_read+0xa0/0x16c
Caller[f007eb38]: sys_read+0x38/0x64
Caller[f0015a3c]: syscall_is_too_hard+0x3c/0x40
Caller[0003df90]: 0x3df98
Instruction DUMP: 1a800003  fa04a00c  a810001b <c207600c> 90100013 
9fc04000  92
100012  80a22000  128000b9
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 0000506a
tsk->{mm,active_mm}->pgd = fc13c800
               \|/ ____ \|/
               "@'/ ,. \`@"
               /_| \__/ |_\
                  \__U_/
tar(13402): Oops [#2]
PSR: 400000c6 PC: f008bd8c NPC: f008bd90 Y: 00000000    Not tainted
PC: <pipe_readv+0xac/0x440>
%G: 00002800 fb478e14  00000104 000000d0  fb478e00 09307866  f882c000 
00000000
%O: f0a4bf00 f0a4bf00  fcfe1000 30306632  30312c30 78613830  f882dd88 
f008c030
RPC: <pipe_readv+0x350/0x440>
%L: 00000000 00000000  fb478f18 fb478e00  00000000 fcfe2000  00000001 
00000001
%I: f882de60 0000000d  f882de60 00002000  fcfe1000 00000000  f882de00 
f008c140
Caller[f008c140]: pipe_read+0x20/0x28
Caller[f007dee8]: vfs_read+0xa0/0x16c
Caller[f007eb38]: sys_read+0x38/0x64
Caller[f0015a3c]: syscall_is_too_hard+0x3c/0x40
Caller[0003df90]: 0x3df98
Instruction DUMP: 1a800003  fa04a00c  a810001b <c207600c> 90100013 
9fc04000  92
100012  80a22000  128000b9

	I think that the trouble I have seen with HyperSPARC comes from the 
same mistake. Any idea ?

	Regards,

	JKB

Re: Sparc32 SMP

[BERTRAND Joël]

	Hello,

	This Oops is reproductible. I have decoded the Oops:

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
dereference
Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->context = 00005058
Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->pgd = fc12d000
Nov 23 14:26:48 hilbert kernel:               \|/ ____ \|/
Nov 23 14:26:48 hilbert kernel:               "@'/ ,. \`@"
Nov 23 14:26:48 hilbert kernel:               /_| \__/ |_\
Nov 23 14:26:48 hilbert kernel:                  \__U_/
Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
Nov 23 14:26:48 hilbert kernel: PSR: 400000c2 PC: f008bd8c NPC: f008bd90 
Y: 00000000    Not tainted
Using defaults from ksymoops -t elf32-sparc -a sparc
Nov 23 14:26:48 hilbert kernel: PC: <pipe_readv+0xac/0x440>
Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
syscall_is_too_hard+0x3c/0x40
Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98
Nov 23 14:26:49 hilbert kernel: Instruction DUMP: 1a800003  fa04a00c 
a810001b <c207600c> 90100013  9fc04000  92100012  80a22000  128000b9


 >>PC;  f008bd8c <pipe_readv+2f8/4d4>   <==
Trace; f008c140 <do_pipe+158/28c>
Trace; f007dee8 <vfs_readv+6c/70>
Trace; f007eb38 <__fput+8c/1b0>
Trace; f0015a3c <linux_sparc_syscall+0/18>
Trace; 0003df90 Before first symbol

Code;  f008bd80 <pipe_readv+2ec/4d4>
00000000 <_PC>:
Code;  f008bd80 <pipe_readv+2ec/4d4>
    0:   1a 80 00 03       bcc  c <_PC+0xc>
Code;  f008bd84 <pipe_readv+2f0/4d4>
    4:   fa 04 a0 0c       ld  [ %l2 + 0xc ], %i5
Code;  f008bd88 <pipe_readv+2f4/4d4>
    8:   a8 10 00 1b       mov  %i3, %l4
Code;  f008bd8c <pipe_readv+2f8/4d4>   <==    c:   c2 07 60 0c       ld  [ %i5 + 0xc ], %g1   <==Code;  f008bd90 <pipe_readv+2fc/4d4>
   10:   90 10 00 13       mov  %l3, %o0
Code;  f008bd94 <pipe_readv+300/4d4>
   14:   9f c0 40 00       call  %g1
Code;  f008bd98 <pipe_readv+304/4d4>
   18:   92 10 00 12       mov  %l2, %o1
Code;  f008bd9c <pipe_readv+308/4d4>
   1c:   80 a2 20 00       cmp  %o0, 0
Code;  f008bda0 <pipe_readv+30c/4d4>
   20:   12 80 00 b9       bne  304 <_PC+0x304>
Code;  f008bda4 <pipe_readv+310/4d4>
   24:   00 00 00 00       unimp  0


1 error issued.  Results may not be reliable.
hilbert:/var/log#

	I don't understand the last message... Any idea ?

	Regards,

	JKB

Re: Sparc32 SMP

[BERTRAND Joël]

BERTRAND Joël a écrit :
>     Hello,
> 
>     This Oops is reproductible. I have decoded the Oops:
> 
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> Nov 23 14:26:47 hilbert kernel: Unable to handle kernel NULL pointer 
> dereference
> Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->context = 00005058
> Nov 23 14:26:48 hilbert kernel: tsk->{mm,active_mm}->pgd = fc12d000
> Nov 23 14:26:48 hilbert kernel:               \|/ ____ \|/
> Nov 23 14:26:48 hilbert kernel:               "@'/ ,. \`@"
> Nov 23 14:26:48 hilbert kernel:               /_| \__/ |_\
> Nov 23 14:26:48 hilbert kernel:                  \__U_/
> Nov 23 14:26:48 hilbert kernel: tar(13387): Oops [#1]
> Nov 23 14:26:48 hilbert kernel: PSR: 400000c2 PC: f008bd8c NPC: f008bd90 
> Y: 00000000    Not tainted
> Using defaults from ksymoops -t elf32-sparc -a sparc
> Nov 23 14:26:48 hilbert kernel: PC: <pipe_readv+0xac/0x440>
> Nov 23 14:26:48 hilbert kernel: Caller[f008c140]: pipe_read+0x20/0x28
> Nov 23 14:26:48 hilbert kernel: Caller[f007dee8]: vfs_read+0xa0/0x16c
> Nov 23 14:26:48 hilbert kernel: Caller[f007eb38]: sys_read+0x38/0x64
> Nov 23 14:26:48 hilbert kernel: Caller[f0015a3c]: 
> syscall_is_too_hard+0x3c/0x40
> Nov 23 14:26:48 hilbert kernel: Caller[0003df90]: 0x3df98
> Nov 23 14:26:49 hilbert kernel: Instruction DUMP: 1a800003  fa04a00c 
> a810001b <c207600c> 90100013  9fc04000  92100012  80a22000  128000b9
> 
> 
>  >>PC;  f008bd8c <pipe_readv+2f8/4d4>   <==> 
> Trace; f008c140 <do_pipe+158/28c>
> Trace; f007dee8 <vfs_readv+6c/70>
> Trace; f007eb38 <__fput+8c/1b0>
> Trace; f0015a3c <linux_sparc_syscall+0/18>
> Trace; 0003df90 Before first symbol
> 
> Code;  f008bd80 <pipe_readv+2ec/4d4>
> 00000000 <_PC>:
> Code;  f008bd80 <pipe_readv+2ec/4d4>
>    0:   1a 80 00 03       bcc  c <_PC+0xc>
> Code;  f008bd84 <pipe_readv+2f0/4d4>
>    4:   fa 04 a0 0c       ld  [ %l2 + 0xc ], %i5
> Code;  f008bd88 <pipe_readv+2f4/4d4>
>    8:   a8 10 00 1b       mov  %i3, %l4
> Code;  f008bd8c <pipe_readv+2f8/4d4>   <==>    c:   c2 07 60 0c       ld  [ %i5 + 0xc ], %g1   <==> Code;  f008bd90 <pipe_readv+2fc/4d4>
>   10:   90 10 00 13       mov  %l3, %o0
> Code;  f008bd94 <pipe_readv+300/4d4>
>   14:   9f c0 40 00       call  %g1
> Code;  f008bd98 <pipe_readv+304/4d4>
>   18:   92 10 00 12       mov  %l2, %o1
> Code;  f008bd9c <pipe_readv+308/4d4>
>   1c:   80 a2 20 00       cmp  %o0, 0
> Code;  f008bda0 <pipe_readv+30c/4d4>
>   20:   12 80 00 b9       bne  304 <_PC+0x304>
> Code;  f008bda4 <pipe_readv+310/4d4>
>   24:   00 00 00 00       unimp  0

	Some news : only occurs with SMP workstation with or without HIGHMEM 
support.

	Regards,

	JKB