From: Christian Schmid <webmaster@rapidforum.com>
To: xfs@oss.sgi.com
Subject: Critical xfs bug in 2.6.17.11?
Date: Sun, 10 Sep 2006 15:37:35 +0200 [thread overview]
Message-ID: <4504151F.6050704@rapidforum.com> (raw)
Hello.
Instead of a tmpfs, I use a raid 10 softraid. Unfortunately it crashed after 10 hours of extreme
activities (read/block-writes with up to 250 streams/deletes)
12 gb memory-test successful. 2 cpu xeon smp system.
Tell me if this helps you:
Sep 9 18:08:49 inode430 kernel: [87433.143498] 0x0: 58 41 47 46 00 00 00 01 00 00 00 00 00 04 34 a0
Sep 9 18:08:49 inode430 kernel: [87433.143672] Filesystem "md5": XFS internal error
xfs_alloc_read_agf at line 2176 of file fs/xfs/xfs_alloc.c. Caller 0xfffffff
f80314069
Sep 9 18:08:49 inode430 kernel: [87433.143904]
Sep 9 18:08:49 inode430 kernel: [87433.143905] Call Trace:
<ffffffff8033c909>{xfs_corruption_error+244}
Sep 9 18:08:49 inode430 kernel: [87433.143995] <ffffffff80346efa>{xfs_iext_insert+65}
<ffffffff803588d1>{xfs_trans_read_buf+203}
Sep 9 18:08:49 inode430 kernel: [87433.144353] <ffffffff803121d9>{xfs_alloc_read_agf+281}
<ffffffff80314069>{xfs_alloc_fix_freelist+356}
Sep 9 18:08:49 inode430 kernel: [87433.144628]
<ffffffff80314069>{xfs_alloc_fix_freelist+356} <ffffffff80515a1f>{__down_read+18}
Sep 9 18:08:49 inode430 kernel: [87433.144855] <ffffffff8031450f>{xfs_alloc_vextent+289}
<ffffffff80323945>{xfs_bmapi+4061}
Sep 9 18:08:49 inode430 kernel: [87433.145091]
<ffffffff803215ba>{xfs_bmap_search_multi_extents+175}
Sep 9 18:08:49 inode430 kernel: [87433.145226]
<ffffffff80349aad>{xfs_iomap_write_allocate+675} <ffffffff80348c29>{xfs_iomap+701}
Sep 9 18:08:49 inode430 kernel: [87433.145473] <ffffffff803797f1>{generic_make_request+515}
<ffffffff803632f3>{xfs_map_blocks+67}
Sep 9 18:08:49 inode430 kernel: [87433.145846]
<ffffffff80363a09>{xfs_page_state_convert+722} <ffffffff80364344>{xfs_vm_writepage+179}
Sep 9 18:08:49 inode430 kernel: [87433.146079] <ffffffff802986ed>{mpage_writepages+459}
<ffffffff80364291>{xfs_vm_writepage+0}
Sep 9 18:08:49 inode430 kernel: [87433.146330] <ffffffff802553c1>{do_writepages+41}
<ffffffff80296de0>{__writeback_single_inode+559}
Sep 9 18:08:49 inode430 kernel: [87433.146583] <ffffffff8022a82c>{default_wake_function+0}
<ffffffff8022a82c>{default_wake_function+0}
Sep 9 18:08:49 inode430 kernel: [87433.146847] <ffffffff80357f56>{xfs_trans_first_ail+28}
<ffffffff802974be>{sync_sb_inodes+501}
Sep 9 18:08:49 inode430 kernel: [87433.147230] <ffffffff802444b4>{keventd_create_kthread+0}
<ffffffff802977cd>{writeback_inodes+144}
Sep 9 18:08:49 inode430 kernel: [87433.147463] <ffffffff802551fc>{wb_kupdate+148}
<ffffffff80255bfd>{pdflush+313}
Sep 9 18:08:49 inode430 kernel: [87433.147825] <ffffffff80255168>{wb_kupdate+0}
<ffffffff80255ac4>{pdflush+0}
Sep 9 18:08:49 inode430 kernel: [87433.148142] <ffffffff80244479>{kthread+218}
<ffffffff8020a992>{child_rip+8}
Sep 9 18:08:49 inode430 kernel: [87433.148420] <ffffffff802444b4>{keventd_create_kthread+0}
<ffffffff8024439f>{kthread+0}
Sep 9 18:08:49 inode430 kernel: [87433.148775] <ffffffff8020a98a>{child_rip+0}
Sep 9 18:08:49 inode430 kernel: [87433.149105] Filesystem "md5": XFS internal error
xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0xffffffff8
0349bf8
Sep 9 18:08:49 inode430 kernel: [87433.149262]
Sep 9 18:08:49 inode430 kernel: [87433.149263] Call Trace: <ffffffff803574e9>{xfs_trans_cancel+111}
Sep 9 18:08:49 inode430 kernel: [87433.149348]
<ffffffff80349bf8>{xfs_iomap_write_allocate+1006} <ffffffff80348c29>{xfs_iomap+701}
Sep 9 18:08:49 inode430 kernel: [87433.149568] <ffffffff803797f1>{generic_make_request+515}
<ffffffff803632f3>{xfs_map_blocks+67}
Sep 9 18:08:49 inode430 kernel: [87433.149847]
<ffffffff80363a09>{xfs_page_state_convert+722} <ffffffff80364344>{xfs_vm_writepage+179}
Sep 9 18:08:49 inode430 kernel: [87433.150169] <ffffffff802986ed>{mpage_writepages+459}
<ffffffff80364291>{xfs_vm_writepage+0}
Sep 9 18:08:49 inode430 kernel: [87433.150435] <ffffffff802553c1>{do_writepages+41}
<ffffffff80296de0>{__writeback_single_inode+559}
Sep 9 18:08:49 inode430 kernel: [87433.150593] <ffffffff8022a82c>{default_wake_function+0}
<ffffffff8022a82c>{default_wake_function+0}
Sep 9 18:08:49 inode430 kernel: [87433.150807] <ffffffff80357f56>{xfs_trans_first_ail+28}
<ffffffff802974be>{sync_sb_inodes+501}
Sep 9 18:08:49 inode430 kernel: [87433.151042] <ffffffff802444b4>{keventd_create_kthread+0}
<ffffffff802977cd>{writeback_inodes+144}
Sep 9 18:08:49 inode430 kernel: [87433.151271] <ffffffff802551fc>{wb_kupdate+148}
<ffffffff80255bfd>{pdflush+313}
Sep 9 18:08:49 inode430 kernel: [87433.151439] <ffffffff80255168>{wb_kupdate+0}
<ffffffff80255ac4>{pdflush+0}
Sep 9 18:08:49 inode430 kernel: [87433.151680] <ffffffff80244479>{kthread+218}
<ffffffff8020a992>{child_rip+8}
Sep 9 18:08:49 inode430 kernel: [87433.151922] <ffffffff802444b4>{keventd_create_kthread+0}
<ffffffff8024439f>{kthread+0}
Sep 9 18:08:49 inode430 kernel: [87433.152086] <ffffffff8020a98a>{child_rip+0}
Sep 9 18:08:49 inode430 kernel: [87433.152489] xfs_force_shutdown(md5,0x8) called from line 1151 of
file fs/xfs/xfs_trans.c. Return address = 0xffffffff80357507
Sep 9 18:08:49 inode430 kernel: [87433.168623] Filesystem "md5": Corruption of in-memory data
detected. Shutting down filesystem: md5
Sep 9 18:08:49 inode430 kernel: [87433.168903] Please umount the filesystem, and rectify the problem(s)
next reply other threads:[~2006-09-10 14:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-10 13:37 Christian Schmid [this message]
2006-09-10 21:31 ` Critical xfs bug in 2.6.17.11? Justin Piszcz
2006-09-10 22:13 ` Christian Schmid
2006-09-10 22:37 ` Justin Piszcz
2006-09-10 23:35 ` Christian Schmid
2006-09-11 1:00 ` David Chinner
2006-09-11 12:31 ` Christian Schmid
2006-09-11 0:54 ` David Chinner
2006-09-11 12:29 ` Christian Schmid
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=4504151F.6050704@rapidforum.com \
--to=webmaster@rapidforum.com \
--cc=xfs@oss.sgi.com \
/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.