Re: BUG at mm/slab.c:662 - current 2.6.13-git (commit 87fc...) crashes on x86-64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph Lameter wrote:
On Sat, 10 Sep 2005, Petr Vandrovec wrote:


Christoph Lameter wrote:

Actually the kernel configuration you mentioned (SMP with K8 NUMA support
booted on single processor) was the primary development platform for the
patch. CONFIG_DEBUG_SLAB=y

Strange...  I had to apply patch below - after doing that everything seems to
be happy and running.  Though it is not right fix, it seems to work fine
here...


Hmmm. That is strange indeed and would mean that one of the initial caches has not correctly been initialized or we are using a smaller cache size than the management caches. With your patch the system fell back to a larger size slab (which seems to be present). Weird.

What is your setting for L1_CACHE_BYTES?

64. Well, at least CONFIG_X86_L1_CACHE_BYTES has this value. Last few lines in /proc/slabinfo in reverse order are:

kmem_cache
size-64
size-128
size-32
size-32(DMA)
size-64(DMA)
size-128(DMA)

so 64 (INDEX_AC) & 128 (INDEX_L3) slabs were created first. But __find_general_cachep BUGs on *first* entry, which is 32 byte one on systems with 4KB pages.

It seems to me that problem is CONFIG_DEBUG_SLAB together with CONFIG_DEBUG_SPINLOCK and/or CONFIG_PREEMPT - in your configuration spinlock_t has 4 bytes, and whole arraycache_init 32 bytes - so it fits into size-32 slab, and you do not hit BUG that size-32 slab does not exist.

On SMP systems with CONFIG_DEBUG_SPINLOCK or CONFIG_PREEMPT spinlock_t is 8 bytes, and so arraycache_init has 36 bytes, and it no longer fits into size-32... And if you'll enable both SPINLOCK debugging and PREEMPT, you get 12 bytes spinlock_t and 40 byte arraycache_init...

So I believe that if you'll rebuild your kernel with PREEMPT or DEBUG_SPINLOCK (or both), you'll get crash I'm seeing. Probably size-32 slab needs to be special cased same way INDEX_AC and INDEX_L3 arrays are.
								Petr Vandrovec

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux