All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zoltan Boszormenyi <zboszor@dunaweb.hu>
To: linux-kernel@vger.kernel.org
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: Bad page state in process 'nfsd' with xfs
Date: Sun, 30 Apr 2006 17:19:56 +0200	[thread overview]
Message-ID: <4454D59C.7000501@dunaweb.hu> (raw)

Hi.

> David Greaves wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > This was with 2.6.16.9
> > 
> > There's an nfs export from an xfs on an lvm on a raid5 on some
> > libata/sata disks.
> > (cc'ing xfs since I recall rumoured(?) badness in old nfs/xfs/md/lvm
> > setups and xfs_sendfile is mentioned)
> > 
> > dmesg had:
> > 
> > Bad page state in process 'nfsd'
> > page:b1602060 flags:0x80000008 mapping:00000000 mapcount:0 count:16777216
> > Trying to fix it up, but a reboot is needed
> > Backtrace:
> >  [<b013bda2>] bad_page+0x62/0x90
> >  [<b013c1c8>] prep_new_page+0x78/0x80
>
> Looks like you have a bit flipped in 'count', which was not flipped
> when the page was last freed. Probably buggy RAM.
>
> Running memtest overnight might confirm that.

Or not. I had an FC3/x86-64 system until two days ago, now I have FC5/86-64.

When FC3 was installed I chose to format the partitions to XFS and since 
then
I had Oopses regularly with or without VMWare modules.
I have run memtest64+ for 12+ hours and it indicated two separate single bit
errors in the topmost  64MB of my 1GB. Since then I was running with
mem=960M but I still got Oopses on a bit heavier disk loads and every time
XFS was involved.

I backed up my /home with rsync to a new harddisk in single mode,
the new disk was formatted to EXT3. During the backup I had Oopses
about 5 or 6 times and I had to reboot. Rsync was able to continue,
that's why I chose that for backup...

I installed FC5 using only EXT3 partitions and copied my 80+ GB data
back to /home. Guess what? No Oopses...

Best regards,
Zoltán Böszörményi


             reply	other threads:[~2006-04-30 15:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-30 15:19 Zoltan Boszormenyi [this message]
2006-05-01  0:24 ` Bad page state in process 'nfsd' with xfs Nathan Scott
2006-05-01  8:07   ` Zoltan Boszormenyi
2006-05-01 21:33     ` Nathan Scott
2006-05-01 22:08       ` Zoltan Boszormenyi
  -- strict thread matches above, loose matches on Subject: below --
2006-04-28 20:22 David Greaves
2006-04-30  2:06 ` Nick Piggin
2006-04-30 22:04 ` Nathan Scott
2006-05-01  9:41   ` David Greaves
2006-05-01 15:21     ` Chris Wedgwood

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=4454D59C.7000501@dunaweb.hu \
    --to=zboszor@dunaweb.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.