lkml.org 
[lkml]   [2004]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard
>
>
>Did that last night. You are right -- it is so slow that it is no fun
>at all. So I started the test run last night and went to bed.
>
>
>
It was a crash in free_block - this means control structures of the slab
allocator were corrupted.

You wrote that enabling everything caused a hard crash without anything
on the console. Could you try what happens if slab debugging is enabled,
but page alloc debugging is off? You should get a verbose BUG_ON() with
kmem_cache_free/kmem_cache_alloc caller addresses and similar stuff.

> EFLAGS: 00010002 (2.6.10)
> EIP is at free_block+0x45/0xd0
> eax: 46484849 ebx: df2b1000 ecx: df2b1050 edx: df2ab000
> esi: c183cd80 edi: 00000001 ebp: 00000018 esp: c188fef8
> ds: 007b es: 007b ss: 0068

Could you compile your kernel without debug and send me mm/slab.o? The
%eax value is odd: FHHI or IHHF.

Btw, if it's still too slow for you without page alloc debug: remove the
forced poisoning:

if ((size < 4096 || fls(size-1) == fls(size-1+3*BYTES_PER_WORD)))
flags |= SLAB_RED_ZONE|SLAB_STORE_USER;
- if (!(flags & SLAB_DESTROY_BY_RCU))
- flags |= SLAB_POISON;
#endif

--
Manfred


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

\
 
 \ /
  Last update: 2005-03-22 14:09    [W:0.026 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site