It seems that I cannot get 2.3.2x running reliably on my dual
P5/133. The box generally dies after a few minutes of high load
(kernel build with make -j4 is one of my favorites), while 2.2.12 is
just rock solid...
This time, I was able to save 2 oops before pressing the Big Red
Button(tm) :
ksymoops 0.7c on i686 2.2.13. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-O (specified)
-m /usr/src/linux/System.map (specified)
e820: 05f00000 @ 00100000 (usable)
e820: 00001000 @ fec00000 (reserved)
e820: 00001000 @ fee00000 (reserved)
e820: 00010000 @ ffff0000 (reserved)
cpu: 1, clocks: 598268, slice: 199422, nr: 2.
cpu: 0, clocks: 598268, slice: 199422, nr: 1.
CPU: 0
EIP: 0010:[<c011920c>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: ffffffff ebx: c13a8000 ecx: 00000000 edx: 0000003b
esi: c13a847c edi: c00ee47c ebp: c00ee000 esp: c13a9f38
ds: 0018 es: 0018 ss: 0018
Process make (pid: 2568, stackpage=c13a9000)
Stack: bfffefb8 c13a9fbc c13a9f98 c13a9f98 0000006b c13a8000 ffffffff fffffff5
00000000 c13a9f98 c13a9f98 c13a9fa0 c13a9fa0 00000000 00000000 00000000
c13a9f98 c13a9f98 c13a9fa0 c13a9fa0 c13a9fa8 00000000 00000000 00000000
Call Trace: [<c0109742>] [<c010afa4>]
Code: 8b 10 39 95 9c 02 00 00 0f 86 a1 08 00 00 f0 ff 00 8b 15 84
>>EIP; c011920c <do_fork+fc/9c0> <=====
Trace; c0109742 <sys_fork+12/20>
Trace; c010afa4 <system_call+34/38>
Code; c011920c <do_fork+fc/9c0>
00000000 <_EIP>:
Code; c011920c <do_fork+fc/9c0> <=====
0: 8b 10 movl (%eax),%edx <=====
Code; c011920e <do_fork+fe/9c0>
2: 39 95 9c 02 00 cmpl %edx,0x29c(%ebp)
Code; c0119213 <do_fork+103/9c0>
7: 00
Code; c0119214 <do_fork+104/9c0>
8: 0f 86 a1 08 00 jbe 8af <_EIP+0x8af> c0119abb <do_fork+9ab/9c0>
Code; c0119219 <do_fork+109/9c0>
d: 00
Code; c011921a <do_fork+10a/9c0>
e: f0 ff 00 lock incl (%eax)
Code; c011921d <do_fork+10d/9c0>
11: 8b 15 84 00 00 movl 0x84,%edx
Code; c0119222 <do_fork+112/9c0>
16: 00
CPU: 0
EIP: 0010:[<c012b7c3>]
EFLAGS: 00010286
eax: 00000073 ebx: c00ea0f8 ecx: c00eaf80 edx: ffffffff
esi: 0000001d edi: c00eaf80 ebp: c1187620 esp: c13a5ed8
ds: 0018 es: 0018 ss: 0018
Process make (pid: 6800, stackpage=c13a5000)
Stack: 00000282 00000015 00000001 00000000 c00eaf80 c01cdcad 00000212 00000001
00000015 00000000 c012ba24 c1187620 00000015 c4a6ac44 c4a6abe0 00000000
c4a44260 c0141288 c1187620 00000015 c4a6ac44 c4a6abe0 00000000 c4a44260
Call Trace: [<c01cdcad>] [<c012ba24>] [<c0141288>] [<c013b015>] [<c013b2a0>] [<c013b369>] [<c01383de>]
[<c010afa4>]
Code: 89 02 8b 12 4e 83 fe ff 75 bb c7 02 00 00 00 00 fa f0 0f ba
>>EIP; c012b7c3 <kmem_cache_grow+2b3/3a0> <=====
Trace; c01cdcad <batch_entropy_process+ad/c0>
Trace; c012ba24 <kmem_cache_alloc+114/190>
Trace; c0141288 <d_alloc+18/160>
Trace; c013b015 <real_lookup+75/160>
Trace; c013b2a0 <lookup_dentry+110/1b0>
Trace; c013b369 <__namei+29/60>
Trace; c01383de <sys_newstat+2e/c0>
Trace; c010afa4 <system_call+34/38>
Code; c012b7c3 <kmem_cache_grow+2b3/3a0>
00000000 <_EIP>:
Code; c012b7c3 <kmem_cache_grow+2b3/3a0> <=====
0: 89 02 movl %eax,(%edx) <=====
Code; c012b7c5 <kmem_cache_grow+2b5/3a0>
2: 8b 12 movl (%edx),%edx
Code; c012b7c7 <kmem_cache_grow+2b7/3a0>
4: 4e decl %esi
Code; c012b7c8 <kmem_cache_grow+2b8/3a0>
5: 83 fe ff cmpl $0xffffffff,%esi
Code; c012b7cb <kmem_cache_grow+2bb/3a0>
8: 75 bb jne ffffffc5 <_EIP+0xffffffc5> c012b788 <kmem_cache_grow+278/3a0>
Code; c012b7cd <kmem_cache_grow+2bd/3a0>
a: c7 02 00 00 00 movl $0x0,(%edx)
Code; c012b7d2 <kmem_cache_grow+2c2/3a0>
f: 00
Code; c012b7d3 <kmem_cache_grow+2c3/3a0>
10: fa cli
Code; c012b7d4 <kmem_cache_grow+2c4/3a0>
11: f0 0f ba lock (bad)
$ cat /proc/version
Linux version 2.3.25 (maz@hina) (gcc version 2.7.2.3) #11 SMP Thu Nov 4 14:39:45 CET 1999
Just in case it might raise someone's eyebrows, the kernel is compiled
on a dual celeron box (much much faster...) with CONFIG_M586TSC set.
.config and other stuff avaible upon request...
M.
-- Places change, faces change. Life is so very strange.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/