From: Andrew Morton <akpm@osdl.org>
To: "Ramón Rey Vicente" <ramon.rey@hispalinux.es>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.6.0-test7-bk][OOPS] Unable to handle kernel paging request at virtual address f9a7e857
Date: Mon, 13 Oct 2003 03:34:59 -0700 [thread overview]
Message-ID: <20031013033459.3519f83b.akpm@osdl.org> (raw)
In-Reply-To: <1065959373.1111.13.camel@debian>
Ramón Rey Vicente <ramon.rey@hispalinux.es> wrote:
>
> Unable to handle kernel paging request at virtual address f9a7e857
> printing eip:
> c0169361
> *pde = 00000000
> Oops: 0000 [#2]
> CPU: 0
> EIP: 0060:[<c0169361>] Not tainted
> EFLAGS: 00010217
> EIP is at mpage_readpages+0x41/0x140
> eax: c01602af ebx: f9a7e853 ecx: caab053c edx: caab053c
> esi: f9a7e84b edi: 00000000 ebp: caab072c esp: cfe03e04
> ds: 007b es: 007b ss: 0068
> Process kswapd0 (pid: 8, threadinfo=cfe02000 task=cfe08ca0)
> Stack: 00000000 00000000 00000000 00000000 cfe03e10 00000000 c02ef348
> c011e55a
> 00000000 00000001 c011e36c 00000046 cfe02000 00000000 00000000
> c02cca00
> c010aaef c0273900 c80b5f40 c80b6c8c cfe02000 00000028 caab072c
> caab072c
> Call Trace:
> [<c011e55a>] tasklet_action+0x3a/0x60
> [<c011e36c>] do_softirq+0x8c/0xa0
> [<c010aaef>] do_IRQ+0xef/0x120
> [<c0180536>] ext3_readpages+0x16/0x20
> [<c01602af>] prune_dcache+0x14f/0x1c0
> [<c017f840>] ext3_get_block+0x0/0x80
> [<c0162b23>] iput+0x63/0x80
> [<c01602af>] prune_dcache+0x14f/0x1c0
> [<c0160753>] shrink_dcache_memory+0x33/0x40
> [<c013a508>] shrink_slab+0x108/0x160
> [<c013b783>] balance_pgdat+0x1c3/0x1e0
> [<c013b89e>] kswapd+0xfe/0x120
> [<c0118c60>] autoremove_wake_function+0x0/0x40
> [<c0108ed6>] ret_from_fork+0x6/0x20
> [<c0118c60>] autoremove_wake_function+0x0/0x40
> [<c013b7a0>] kswapd+0x0/0x120
> [<c0107061>] kernel_thread_helper+0x5/0x24
You get the award for the weirdest bug report of the 21st century. There
is just no way in which kswapd can call ->readpages().
The only thing I can think of is that an inode's superblock's ->put_inode
pointer somehow got set to point at ext3_readpages(). Or we got a
completely wild pointer in prune_dcache(). Some sort of memory scribble,
anyway.
What sort of machine is it? Nice, new and stable or old, nasty and likely
to tromp its memory?
next prev parent reply other threads:[~2003-10-13 10:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-12 11:49 Ramón Rey Vicente
2003-10-13 10:34 ` Andrew Morton [this message]
2003-10-13 14:59 ` Ramón Rey Vicente
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=20031013033459.3519f83b.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ramon.rey@hispalinux.es \
/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
all inboxes | Powered by JetHome®