yesterday our server machine crashed with an oops in
kmem_cache_free. The oops looks like follows:
Unable to handle kernel paging request at virtual address ffaffe18
current -> tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
CPU: 1
EIP: 0010:[<c012263b>]
EFLAGS: 00010086
eax: c9ea7c5c ebx: c009e6e0 ecx: ffaffe10 edx: c9ea7c00
esi: c9ea7c00 edi: 00000286 ebp: c9ea7a20 esp: c0091f48
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 3, process nr: 6, stackpage = c0091000)
Stack: c0091fb4 c9ea7a20 c0004000 c9ea7c5c 00000006 c01294f0 c009e6e0 c9ea7c00
c0091fb4 c0129ffd c9ea7c00 c03d9130 00000014 00000002 00000fdf c7db1000
c011e477 c9ea7a20 c0091fb4 00000006 00000006 00000002 00000003 c0090000
Call Trace: [<c01294f0>] [<c0129ffd>] [<c011e477>] [<c01236e3>]
[<c012392d>] [<c01080ae>] [<c01237f4>]
[<c0107fdc>]
Code: 8b 69 08 81 fd 2b 2f c3 a5 0f 85 fe 00 00 00 8b 69 0c 85 ed
Using ksymoops we get the following:
>>EIP: c012263b <kmem_cache_free+43/19c>
Trace: c01294f0 <put_unused_buffer_head+20/4c>
Trace: c0129ffd <try_to_free_buffer+1b9/218>
Trace: c011e477 <shrink_mmap+19b/20c>
Trace: c01236e3 <do_try_to_free_page+6b/110>
Trace: c012392d <kswapd+139/180>
Trace: c01080ae <init+42/1b0>
Trace: c012392d <kswapd+139/180>
Trace: c0107fdc <this_must_match_init_task+1fdc/2000>
Code: c012263b <kmem_cache_free+43/19c>
Code: c012263b <kmem_cache_free+43/19c> 8b 69 08 movl 0x8(%ecx),%ebp
Code: c012263e <kmem_cache_free+46/19c> 81 fd 2b 2f c3 cmpl $0xa5c32f2b,%ebp
Code: c0122644 <kmem_cache_free+4c/19c> 0f 85 fe 00 00 jne c0122748 <kmem_cache_free+150/19c>
Code: c012264a <kmem_cache_free+52/19c> 8b 69 0c movl 0xc(%ecx),%ebp
Code: c012264d <kmem_cache_free+55/19c> 85 ed testl %ebp,%ebp
The relevant lines from slab.c:
check_magic:
if (slabp->s_magic != SLAB_MAGIC_ALLOC) /* Sanity check. */
goto bad_slab;
/home/jw5/tmp/linux/linux/mm/slab.c:1504
ceb: 8b 69 08 movl 0x8(%ecx),%ebp
cee: 81 fd 2b 2f c3 cmpl $0xa5c32f2b,%ebp
cf3: a5
cf4: 0f 85 fe 00 00 jne df8 <kmem_cache_free+0x150>
cf9: 00
/home/jw5/tmp/linux/linux/mm/slab.c:1513
cfa: 8b 69 0c movl 0xc(%ecx),%ebp
cfd: 85 ed testl %ebp,%ebp
cff: 0f 84 87 00 00 je d8c <kmem_cache_free+0xe4>
d04: 00
Somehow the 'slabp' pointer is pretty bogus and leads to the oops.
The machine in question is an AMI Goliath equipped with 4 PPro and
256MB memory.
The kernel is a stock 2.1.115, /proc/interupts reports
0: IO-APIC-edge timer
1: IO-APIC-edge keyboard
2: XT-PIC cascade
3: IO-APIC-edge NE2000
7: IO-APIC-edge Digital DS21140 Tulip
9: IO-APIC-edge ncr53c8xx
10: IO-APIC-edge ncr53c8xx
13: XT-PIC fpu
The config looks like follows:
CONFIG_M686=y
CONFIG_MODULES=y
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_BIOS=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_STRIPED=y
CONFIG_MD_BOOT=y
CONFIG_BLK_DEV_RAM=y
CONFIG_PARIDE_PARPORT=y
CONFIG_PACKET=y
CONFIG_NET_ALIAS=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ALIAS=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_RARP=y
CONFIG_IP_NOSR=y
CONFIG_SKB_LARGE=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_BUSLOGIC=y
CONFIG_SCSI_OMIT_FLASHPOINT=y
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
CONFIG_SCSI_NCR53C8XX_SYNC=20
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
CONFIG_NET_ISA=y
CONFIG_NE2000=y
CONFIG_NET_EISA=y
CONFIG_DE4X5=y
CONFIG_DEC_ELCP=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_MINIX_FS=y
CONFIG_EXT2_FS=y
CONFIG_ISO9660_FS=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_PROC_FS=y
CONFIG_NFS_FS=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_SMB_FS=y
CONFIG_AUTOFS_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_NLS=y
CONFIG_VGA_CONSOLE=y
CONFIG_MAGIC_SYSRQ=y
Jean
-- I get up each morning, gather my wits. Pick up the paper, read the obits. if I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. Peete Seeger- 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.altern.org/andrebalsa/doc/lkml-faq.html