From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Julien Kirmaier <julien.kirmaier@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: kernel BUG at mm/swap.c:340
Date: Sat, 21 Oct 2006 01:26:30 +1000 [thread overview]
Message-ID: <4538EAA6.6010606@yahoo.com.au> (raw)
In-Reply-To: <20061020095456.GA24360@thabor.lan.ah2d.fr>
Julien Kirmaier wrote:
> Dear kernel maintainers,
>
> while processing with gs rather large postscript files (~1Go) the kernel
> pulled this message in the console:
>
> <<<<<
> kernel BUG at mm/swap.c:340!
So it found PageLRU set when it should not have been.
> invalid opcode: 0000 [#1]
> Modules linked in: parport_serial bsd_comp ppp_deflate zlib_deflate
> ppp_synctty ppp_generic slhc via_rhine nfs lockd sunrpc smbfs ntfs vfat fat
> genrtc
> CPU: 0
> EIP: 0060:[<c01367b2>] Not tainted VLI
> EFLAGS: 00010202 (2.6.18 #2)
> EIP is at __pagevec_release_nonlru+0x26/0x71
> eax: ffffffff ebx: c1ad7e24 ecx: 00000007 edx: c158f848
> esi: f1d57ca0 edi: f1d57ca0 ebp: c1ad7f2c esp: c1ad7dc0
> ds: 007b es: 007b ss: 0068
> Process kswapd0 (pid: 79, ti=c1ad6000 task=c19e8570 task.ti=c1ad6000)
> Stack: 00000007 00000001 c148c1e0 c15a5c80 c1691b80 c134a800 c1336120 c117c340
> c10a5600 00018a8e c10f3040 c10f3040 c0137389 c10f3040 c10f3040 c10f3040
> c10f3040 c013764c c1ad7e24 00000001 00000001 0000001c 00000000 c1ad7e1c
> Call Trace:
> [<c0137389>] remove_mapping+0x4a/0x5c
> [<c013764c>] shrink_page_list+0x2b1/0x33d
> [<c013780c>] shrink_inactive_list+0x78/0x1bb
> [<c0137071>] shrink_slab+0x61/0x18c
> [<c013718d>] shrink_slab+0x17d/0x18c
> [<c0137d37>] shrink_zone+0xa9/0xc6
> [<c01380f4>] balance_pgdat+0x1b5/0x2c0
> [<c01382f4>] kswapd+0xf5/0xf9
Looks like either the isolated list of pages got messed up, or the page
flag flipped from !PageLRU when we isolated it, to PageLRU when we check
it again here.
If I'm not mistaken, page->flags should be in eax, which which may point
to the list being messed up rather than a flags bitflip.
Either way I'd say you have some memory corruption problems, whether it
is bad memory or a device/driver problem. Hard to help.
You could try running a 2.6.19-rc2 kernel with CONFIG_DEBUG_LIST and
CONFIG_DEBUG_VM turned on and see if that catches anything.
> The machine did not halt after this message as it did two weeks ago. I
> thought at the time that bad RAM was involved so I replaced it; memtest86
> did not return anything wrong with the new 1Go RAM module.
>
> I'm running 2.6.18 vanilla kernel on Debian Sarge, raid-1 software, the
> swap space is also on raid1.
>
> Tell me if you need more informations (or to whom I should address this
> message if linux.kernel is not relevant).
linux.kernel is the right place. Thanks.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
prev parent reply other threads:[~2006-10-20 15:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-20 9:54 kernel BUG at mm/swap.c:340 Julien Kirmaier
2006-10-20 15:26 ` Nick Piggin [this message]
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=4538EAA6.6010606@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=julien.kirmaier@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox