From: Nathan Scott <nathans@sgi.com>
To: Oliver Kiddle <okiddle@yahoo.co.uk>
Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com
Subject: Re: xfs and page allocation failures
Date: Wed, 7 Apr 2004 16:23:14 +1000 [thread overview]
Message-ID: <20040407162314.A10240@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <22084.1081244015@trentino.logica.co.uk>; from okiddle@yahoo.co.uk on Tue, Apr 06, 2004 at 11:33:35AM +0200
Hi there,
On Tue, Apr 06, 2004 at 11:33:35AM +0200, Oliver Kiddle wrote:
> I posted back in January about problems I was having with 2.6.1. Thanks
> for the help back then. I'm still having problems with the same
> machine, though.
>
> 2.6.3 is usable (just three page allocation failures printed when I run
> xfsdump). xfsdump crashed 2.6.4 and I never got around to trying to
> capture the console output. I tried 2.6.5 yesterday and have had two
> issues. The first, relatively harmless problem was two page allocation
> failures printed when running xfsdump (output is below).
>
> Then, this morning, mountd was no longer working. NFS was still happily
> working where clients had mounted the filesystems. rpcinfo -u was
> getting a timeout for mountd. I tried first restarting rpc.mountd which
> had no effect and then tried `/etc/init.d/nfs-kernel-server restart',
> also to no effect.
>
> I've attached the relevant part of the dmesg output below.
>
> Thanks
>
> Oliver
>
> st0: Block limits 1 - 16777215 bytes.
> xfsdump: page allocation failure. order:9, mode:0xd0
> Call Trace:
> [<c012d79f>] __alloc_pages+0x2e0/0x325
> [<c02ad92d>] enlarge_buffer+0xcf/0x182
This is xfsdump making requests of the SCSI tape driver with buffers
which are too large for it to pin down, the warning is harmless and
ST chugs on. I believe the warnings will be fixed in future kernels,
and xfsdump/xfsrestore will need some tweaks to use more appropriately
sized buffers.
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> EIP is at free_block+0x48/0xc8
> Process kswapd0 (pid: 7, threadinfo=c1b74000 task=c1b791e0)
> Call Trace:
> [<c0130296>] cache_flusharray+0x3f/0xbc
> [<c013045f>] kmem_cache_free+0x48/0x4c
> [<c02119fa>] linvfs_destroy_inode+0x1b/0x1f
This looks like a use-after-free - freeing an inode for a second
time, I think - I haven't come across this one before. I expect
the second oops and pagebuf warnings will be a follow-on effect
from this initial failure. The initial failure will need some
more investigation - if you can reliably hit it pls let me know
what/how you're doing that.
thanks.
--
Nathan
prev parent reply other threads:[~2004-04-07 6:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-06 9:33 xfs and page allocation failures Oliver Kiddle
2004-04-07 6:23 ` Nathan Scott [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=20040407162314.A10240@wobbly.melbourne.sgi.com \
--to=nathans@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=okiddle@yahoo.co.uk \
/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;
as well as URLs for NNTP newsgroup(s).