2005-09-27 20:29:03

by lapinlam

[permalink] [raw]
Subject: 2.6.14-rc2 early boot OOPS (mm/slab.c:1767)


Hi,

I'm getting the following OOPS with 2.6.14-rc2 on an Alpha.

The OOPS is repeatable. 2.6.13 works fine on this box (except for some
strange problems with st.ko staying in "Loading" state and never
entering "Live" state in /proc/modules). Here's the OOPS:

Linux version 2.6.14-rc2 (lapinlam@raato) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #15 Mon Sep 26 23:12:20 EEST 2005
Booting on Alcor variation Alcor using machine vector Alcor from SRM
Major Options: LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ
Command line: console=ttyS0
memcluster 0, usage 1, start 0, end 161
memcluster 1, usage 0, start 161, end 32651
memcluster 2, usage 1, start 32651, end 32768
freeing pages 161:384
freeing pages 767:32651
reserving pages 767:768
2048K Bcache detected; load hit latency 24 cycles, load miss latency 88 cycles
pci: cia revision 1
Built 1 zonelists
Kernel command line: console=ttyS0
PID hash table entries: 1024 (order: 10, 32768 bytes)
Using epoch = 2000
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 5, 262144 bytes)
Memory: 253560k/261208k available (1977k kernel code, 5696k reserved, 294k data, 152k init)
Kernel bug at mm/slab.c:1767
swapper(0): Kernel Bug 1
pc = [<fffffc00003593ec>] ra = [<fffffc000035939c>] ps = 0000 Not tainted
pc is at kmem_cache_create+0x6dc/0x800
ra is at kmem_cache_create+0x68c/0x800
v0 = 0000000000000000 t0 = 0000000000000001 t1 = fffffc0000593ca8
t2 = 00000000000000d0 t3 = fffffc0000593df8 t4 = 0000000000000001
t5 = ffffffffffffffff t6 = fffffc00005821d8 t7 = fffffc0000588000
a0 = 0000000000000000 a1 = 00000000000000d0 a2 = 0000000000000001
a3 = 00000000000000d0 a4 = 0000000000000000 a5 = 0000000000000000
t8 = 0000000000000000 t9 = 00000000ffffffff t10= 0000000000200200
t11= 0000000000100100 pv = 0000000000000000 at = fffffc00005821e8
gp = fffffc00005d7700 sp = fffffc000058be18
Trace:
[<fffffc000031001c>] __start+0x1c/0x20


Code: b7e00050 b7e00030 a59dbc78 ed7fffeb c3ffff4f 00000081 <000006e7> 0050dad7
Kernel panic - not syncing: Attempted to kill the idle task!


The system is an Alphastation 600 5/266, system variation Alcor.

raato% cat /proc/cpuinfo
cpu : Alpha
cpu model : EV5
cpu variation : 7
cpu revision : 0
cpu serial number :
system type : Alcor
system variation : Alcor
system revision : 0
system serial number :
cycle frequency [Hz] : 266666666
timer frequency [Hz] : 1024.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS : 528.12
kernel unaligned acc : 0 (pc=0,va=0)
user unaligned acc : 0 (pc=0,va=0)
platform string : Digital AlphaStation 600 5/266
cpus detected : 1
L1 Icache : 8K, 1-way, 32b line
L1 Dcache : 8K, 1-way, 32b line
L2 cache : 96K, 3-way, 64b line
L3 cache : 2048K, 1-way, 64b line


.config is attached below.

Please CC me on this since I'm not currently on the list.

Regards,

Tomi

--
You can decide: live with free software or with only one evil company left?


Attachments:
(No filename) (3.17 kB)
raato-2.6.14-rc2 (23.30 kB)
Download all attachments

2005-09-27 23:36:05

by Christoph Lameter

[permalink] [raw]
Subject: Re: 2.6.14-rc2 early boot OOPS (mm/slab.c:1767)

On Tue, 27 Sep 2005, Tomi Lapinlampi wrote:

> I'm getting the following OOPS with 2.6.14-rc2 on an Alpha.

Hmmm. I am not familiar with Alpha. The .config looks as if this is a
uniprocessor configuration? No NUMA?

What is the value of MAX_NUMNODES?

2005-09-28 06:30:22

by lapinlam

[permalink] [raw]
Subject: Re: 2.6.14-rc2 early boot OOPS (mm/slab.c:1767)

On Tue, Sep 27, 2005 at 04:35:54PM -0700, Christoph Lameter wrote:
> On Tue, 27 Sep 2005, Tomi Lapinlampi wrote:
>
> > I'm getting the following OOPS with 2.6.14-rc2 on an Alpha.
>
> Hmmm. I am not familiar with Alpha. The .config looks as if this is a
> uniprocessor configuration? No NUMA?

This is a simple uniprocessor configuration, no NUMA, no SMP.

> What is the value of MAX_NUMNODES?

I'm not familiar with NUMA, where can I check this (or does this question
even apply since it's not a NUMA system) ?

Plase keep me cc:'d,

Tomi

--
You can decide: live with free software or with only one evil company left?

2005-09-28 06:48:45

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.14-rc2 early boot OOPS (mm/slab.c:1767)

[email protected] (Tomi Lapinlampi) wrote:
>
> On Tue, Sep 27, 2005 at 04:35:54PM -0700, Christoph Lameter wrote:
> > On Tue, 27 Sep 2005, Tomi Lapinlampi wrote:
> >
> > > I'm getting the following OOPS with 2.6.14-rc2 on an Alpha.
> >
> > Hmmm. I am not familiar with Alpha. The .config looks as if this is a
> > uniprocessor configuration? No NUMA?
>
> This is a simple uniprocessor configuration, no NUMA, no SMP.

It might be due to the indev_of()-doesn't-get-inlined problem. I'm not
sure what the symptoms of that were. Please try
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.14-rc2-git6.gz
which has fixes.

2005-09-28 17:08:27

by Christoph Lameter

[permalink] [raw]
Subject: Re: 2.6.14-rc2 early boot OOPS (mm/slab.c:1767)

On Wed, 28 Sep 2005, Tomi Lapinlampi wrote:

> > Hmmm. I am not familiar with Alpha. The .config looks as if this is a
> > uniprocessor configuration? No NUMA?
>
> This is a simple uniprocessor configuration, no NUMA, no SMP.
>
> > What is the value of MAX_NUMNODES?
>
> I'm not familiar with NUMA, where can I check this (or does this question
> even apply since it's not a NUMA system) ?

Well, one use of memory nodes is to describe discontiguous memory on some
architectures. Thus the number of nodes may be more than one even if
CONFIG_NUMA is off. This is the case f.e. on ppc64. There may be some arch
specific settings that cause problems here.