From: David Greaves <david@dgreaves.com>
To: Andrew Morton <akpm@osdl.org>
Cc: phil@dier.us, linux-kernel@vger.kernel.org
Subject: Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs
Date: Wed, 08 Dec 2004 09:03:07 +0000 [thread overview]
Message-ID: <41B6C34B.7030700@dgreaves.com> (raw)
In-Reply-To: <20041128102751.2dac71f7.akpm@osdl.org>
Andrew Morton wrote:
>David Greaves <david@dgreaves.com> wrote:
>
>
>>...
>>I have a system that's running 2.6.10rc2
>>It has libata sata_promise + sata_sil drives in an md raid5 array that's
>>used by lvm2 and then xfs; then exported via nfs.
>>I saw this thread, upgraded to 2.6.10rc2 and I'm posting this in case
>>it's related (it's hard to tell)
>>
>>This oops happened whilst the box was quiet
>>
>>Hopefully relevant config bits:
>>Single processor
>>echo 16384 > /proc/sys/vm/min_free_kbytes
>>CONFIG_4KSTACKS=n
>>I've done a memtest.
>>I haven't applied the inode patch - I'm usually writing a single 1-3Gb
>>files whilst reading another.
>>
>>Can I help by providing anything else?
>>
>>Nov 28 09:05:03 cu kernel: Unable to handle kernel paging request at
>>virtual address 00100104
>>
>>
>
>That's the list_del() poisoning pattern.
>
>
<snip old log>
>It appears that the dentry cache's slab freelists have become corrupted.
>Odd, because everyone uses that code a lot. I'd suggest that you enable
>CONFIG_DEBUG_SLAB, see if that catches anything.
>
>
Thanks for the reply Andrew.
I did as you suggested and it's been fine until I got this last night.
Dec 8 06:50:04 cu kernel: slab: Internal list corruption detected in
cache 'vm_area_struct'(41), slabp cfedd000(13). Hexdump:
Dec 8 06:50:04 cu kernel:
Dec 8 06:50:04 cu kernel: 000: 00 01 10 00 00 02 20 00 6c 00 00 00 6c
d0 ed cf
Dec 8 06:50:04 cu kernel: 010: 0d 00 00 00 11 00 14 08 1a 00 fe ff 0a
00 06 00
Dec 8 06:50:04 cu kernel: 020: fe ff fe ff 02 00 fe ff 22 00 21 00 18
00 27 00
Dec 8 06:50:04 cu kernel: 030: ff ff fe ff fe ff 03 00 00 00 19 00 03
00 fe ff
Dec 8 06:50:04 cu kernel: 040: fe ff 08 00 fe ff fe ff 1c 00 10 00 15
00 fe ff
Dec 8 06:50:04 cu kernel: 050: 25 00 12 00 fe ff
Dec 8 06:50:04 cu kernel: ------------[ cut here ]------------
Dec 8 06:50:04 cu kernel: kernel BUG at mm/slab.c:1947!
Dec 8 06:50:04 cu kernel: invalid operand: 0000 [#1]
Dec 8 06:50:04 cu kernel: Modules linked in: nfs af_packet ipv6 e100
mii usblp uhci_hcd usbcore nfsd exportfs lockd sunrpc sk98lin unix
Dec 8 06:50:04 cu kernel: CPU: 0
Dec 8 06:50:04 cu kernel: EIP: 0060:[check_slabp+180/240] Not
tainted VLI
Dec 8 06:50:04 cu kernel: EFLAGS: 00010092 (2.6.10-rc2cu-041128-02)
Dec 8 06:50:04 cu kernel: EIP is at check_slabp+0xb4/0xf0
Dec 8 06:50:04 cu kernel: eax: 00000001 ebx: 00000056 ecx:
00000082 edx: 0000898d
Dec 8 06:50:04 cu kernel: esi: cfedd000 edi: dffe9960 ebp:
cfedd018 esp: c1f3bca8
Dec 8 06:50:04 cu kernel: ds: 007b es: 007b ss: 0068
Dec 8 06:50:04 cu kernel: Process munin-node (pid: 6456,
threadinfo=c1f3a000 task=c32dea00)
Dec 8 06:50:04 cu kernel: Stack: c0352d03 000000ff 00000029 cfedd000
0000000d cfedd000 0000001b cfedda8c
Dec 8 06:50:04 cu kernel: c013aa19 dffe9960 cfedd000 00000000
dffe996c dffe997c 0000000c 00000010
Dec 8 06:50:04 cu kernel: dffe9960 c094ba2c dffea728 c013ab2b
dffe9960 dffe65e8 00000010 dffe65e8
Dec 8 06:50:04 cu kernel: Call Trace:
Dec 8 06:50:04 cu kernel: [free_block+153/336] free_block+0x99/0x150
Dec 8 06:50:04 cu kernel: [cache_flusharray+91/304]
cache_flusharray+0x5b/0x130
Dec 8 06:50:04 cu kernel: [kmem_cache_free+122/128]
kmem_cache_free+0x7a/0x80
Dec 8 06:50:04 cu kernel: [remove_vm_struct+94/128]
remove_vm_struct+0x5e/0x80
Dec 8 06:50:04 cu kernel: [remove_vm_struct+94/128]
remove_vm_struct+0x5e/0x80
Dec 8 06:50:04 cu kernel: [exit_mmap+284/320] exit_mmap+0x11c/0x140
Dec 8 06:50:04 cu kernel: [mmput+44/128] mmput+0x2c/0x80
Dec 8 06:50:04 cu kernel: [exec_mmap+121/240] exec_mmap+0x79/0xf0
Dec 8 06:50:04 cu kernel: [flush_old_exec+202/1616]
flush_old_exec+0xca/0x650
Dec 8 06:50:04 cu kernel: [kernel_read+80/96] kernel_read+0x50/0x60
Dec 8 06:50:04 cu kernel: [load_elf_binary+827/3184]
load_elf_binary+0x33b/0xc70
Dec 8 06:50:04 cu kernel: [get_empty_filp+70/208] get_empty_filp+0x46/0xd0
Dec 8 06:50:04 cu kernel: [autoremove_wake_function+0/96]
autoremove_wake_function+0x0/0x60
Dec 8 06:50:04 cu kernel: [kernel_read+80/96] kernel_read+0x50/0x60
Dec 8 06:50:04 cu kernel: [search_binary_handler+93/432]
search_binary_handler+0x5d/0x1b0
Dec 8 06:50:04 cu kernel: [load_script+520/576] load_script+0x208/0x240
Dec 8 06:50:04 cu kernel: [__alloc_pages+458/864]
__alloc_pages+0x1ca/0x360
Dec 8 06:50:04 cu kernel: [copy_from_user+66/128] copy_from_user+0x42/0x80
Dec 8 06:50:04 cu kernel: [copy_strings+392/512] copy_strings+0x188/0x200
Dec 8 06:50:04 cu kernel: [search_binary_handler+93/432]
search_binary_handler+0x5d/0x1b0
Dec 8 06:50:04 cu kernel: [do_execve+409/528] do_execve+0x199/0x210
Dec 8 06:50:04 cu kernel: [sys_execve+66/128] sys_execve+0x42/0x80
Dec 8 06:50:04 cu kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Dec 8 06:50:04 cu kernel: Code: b6 04 33 43 c7 04 24 94 59 34 c0 89 44
24 04 e8 23 d7 fd ff 8b 47 3c 8d 44 00 04 39 c3 72 db c7 04 24 03 2d 35
c0 e8 0c d7 fd ff <0f> 0b 9b 07 1e 58 34 c0 83 c4 14 5b 5e 5f c3 89 5c
24 04 c7 04
Additional info:
when the machine started I got three:
swapper: page allocation failure. order:1, mode:0x20
before I could:
echo 16384 > /proc/sys/vm/min_free_kbytes
Anything else you'd like me to try?
David
next prev parent reply other threads:[~2004-12-08 9:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-22 19:06 oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs Phil Dier
2004-11-23 0:17 ` Andrew Morton
2004-11-23 15:37 ` Phil Dier
2004-11-23 17:02 ` Jakob Oestergaard
2004-11-23 18:29 ` Phil Dier
2004-11-23 22:39 ` Christoph Hellwig
2004-11-23 22:56 ` Jakob Oestergaard
2004-11-23 23:12 ` Christoph Hellwig
2004-11-30 17:37 ` Phil Dier
2004-11-24 15:45 ` Phil Dier
2004-11-24 16:56 ` Christoph Hellwig
2004-11-24 23:12 ` Andrew Morton
2004-11-25 0:48 ` Phil Dier
2004-11-28 11:29 ` David Greaves
2004-11-28 18:27 ` Andrew Morton
2004-12-08 9:03 ` David Greaves [this message]
2004-12-08 9:15 ` Andrew Morton
2004-12-09 3:50 ` Nigel Cunningham
2004-11-24 23:12 ` Neil Brown
2004-11-24 23:50 ` Andrew Morton
2004-11-25 0:14 ` Neil Brown
2004-11-25 1:05 ` Andrew Morton
2004-11-25 6:57 ` Jens Axboe
2004-11-25 7:08 ` Andrew Morton
2004-11-25 7:11 ` Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2004-11-23 20:48 Joerg Sommrey
2004-11-24 9:28 Anders Saaby
[not found] <33rTj-1VZ-13@gated-at.bofh.it>
[not found] ` <33wJq-633-25@gated-at.bofh.it>
[not found] ` <34fwL-P1-21@gated-at.bofh.it>
[not found] ` <34fGp-V2-9@gated-at.bofh.it>
[not found] ` <34fGp-V2-7@gated-at.bofh.it>
[not found] ` <34lVr-5WH-1@gated-at.bofh.it>
[not found] ` <34m5a-61Z-9@gated-at.bofh.it>
2004-11-25 11:07 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41B6C34B.7030700@dgreaves.com \
--to=david@dgreaves.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phil@dier.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.