From: David Martinez Moreno <ender@debian.org>
To: linux-kernel@vger.kernel.org, nathans@sgi.com
Cc: ender@debian.org
Subject: Crashes and lockups in XFS filesystem (2.6.8-rc4).
Date: Wed, 18 Aug 2004 18:16:57 +0200 [thread overview]
Message-ID: <200408181816.57940.ender@debian.org> (raw)
Hello, I am getting persistent lockups that could be IMHO XFS-related. I
created a fresh XFS filesystem in a SCSI disk, with xfsprogs version 2.6.18.
Mounted /dev/sda1 under /mnt, after that, I have been copying lots of files
from /dev/md0, then run a find blabla -exec rm \{\{ \; over /mnt and then
voilà! the lockup:
ulises:/mnt/debian# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda5 5,6G 1,8G 3,5G 34% /
tmpfs 252M 0 252M 0% /dev/shm
/dev/hda1 19M 11M 6,9M 62% /boot
/dev/hda6 9,2G 1,8G 7,0G 21% /var
/dev/hda8 3,7G 2,3G 1,2G 67% /home
/dev/md0 224G 182G 42G 82% /mirror
/dev/sda1 69G 56G 13G 82% /mnt
ulises:/mnt/debian# find . \( -name *m68k.deb \) -exec rm \{\} \; &
[1] 13215
ulises:/mnt/debian# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda5 5,6G 1,8G 3,5G 34% /
tmpfs 252M 0 252M 0% /dev/shm
/dev/hda1 19M 11M 6,9M 62% /boot
/dev/hda6 9,2G 1,8G 7,0G 21% /var
/dev/hda8 3,7G 2,3G 1,2G 67% /home
Segmentation fault <<<<<< when trying to display free space in /mnt
ulises:/mnt/debian# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda5 5767428 1839536 3634920 34% /
tmpfs 257484 0 257484 0% /dev/shm
/dev/hda1 18998 11044 6973 62% /boot
/dev/hda6 9612100 1874984 7248844 21% /var
/dev/hda8 3799944 2398188 1208728 67% /home
Segmentation fault
ulises:~# dmesg
[...]
XFS mounting filesystem sda1
Starting XFS recovery on filesystem: sda1 (dev: sda1)
Ending XFS recovery on filesystem: sda1 (dev: sda1)
Unable to handle kernel paging request at virtual address 020000b4
printing eip:
c01fcd41
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01fcd41>] Not tainted
EFLAGS: 00010206 (2.6.8-rc4)
EIP is at xfs_log_force+0x28/0x6c
eax: 02000000 ebx: 00000002 ecx: 00000000 edx: 00000000
esi: df234c40 edi: dacae2f4 ebp: 00000000 esp: dec44f64
ds: 007b es: 007b ss: 0068
Process xfssyncd (pid: 174, threadinfo=dec44000 task=dee7a8c0)
Stack: dffabc80 00000000 00000031 c0207bba 00000031 df234c40 c020f59d dacae2f4
00000000 00000000 00000002 004bcd64 dec44fb0 00000000 00000002 00000000
dec44000 df234c40 00000000 00000000 c020ec0f dacae2f4 00000031 00000000
Call Trace:
[<c0207bba>] xfs_getsb+0x2f/0x45
[<c020f59d>] xfs_syncsub+0x4e/0x303
[<c020ec0f>] xfs_sync+0x29/0x2d
[<c02211cc>] vfs_sync+0x34/0x38
[<c022076f>] xfssyncd+0x7e/0xce
[<c02206f1>] xfssyncd+0x0/0xce
[<c0101fdd>] kernel_thread_helper+0x5/0xb
Code: f6 80 b4 00 00 00 08 75 34 89 ce 09 d6 75 18 89 5c 24 04 89
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
c020ebb4
*pde = 00000000
Oops: 0000 [#2]
CPU: 0
EIP: 0060:[<c020ebb4>] Not tainted
EFLAGS: 00010202 (2.6.8-rc4)
EIP is at xfs_statvfs+0xb6/0xe8
eax: 00000000 ebx: dacae314 ecx: dacae2f4 edx: 00000000
esi: dacae2f4 edi: 00000000 ebp: c0cf1ebc esp: c0cf1e68
ds: 007b es: 007b ss: 0068
Process df (pid: 30308, threadinfo=c0cf1000 task=c64726c0)
Stack: dacae2f4 00000000 c0cf1f74 c0cf1efc c0cf1000 c0221194 dfced400 c0cf1ebc
00000000 c0220b0a dfced400 c0cf1ebc 00000000 c013e3af c154ce00 c0cf1ebc
c0cf1f14 c013e430 c154ce00 c0cf1ebc d24a1001 58465342 00000000 bfeb0fdc
Call Trace:
[<c0221194>] vfs_statvfs+0x34/0x38
[<c0220b0a>] linvfs_statfs+0x28/0x2e
[<c013e3af>] vfs_statfs+0x4b/0x66
[<c013e430>] vfs_statfs64+0x23/0xb2
[<c013e5ea>] sys_statfs64+0x81/0xbf
[<c024fac4>] tty_write+0x179/0x1bc
[<c0254921>] write_chan+0x0/0x219
[<c024f94b>] tty_write+0x0/0x1bc
[<c01403e9>] vfs_write+0xc9/0x119
[<c014050a>] sys_write+0x51/0x80
[<c0103aa1>] sysenter_past_esp+0x52/0x71
Code: 8b 00 c7 45 24 ff 00 00 00 89 c2 0f b6 c8 25 00 ff 0f 00 c1
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
c020ebb4
*pde = 00000000
Oops: 0000 [#3]
CPU: 0
EIP: 0060:[<c020ebb4>] Not tainted
EFLAGS: 00010202 (2.6.8-rc4)
EIP is at xfs_statvfs+0xb6/0xe8
eax: 00000000 ebx: dacae314 ecx: dacae2f4 edx: 00000000
esi: dacae2f4 edi: 00000000 ebp: c987cebc esp: c987ce68
ds: 007b es: 007b ss: 0068
Process df (pid: 30728, threadinfo=c987c000 task=c156abd0)
Stack: dacae2f4 00000000 c987cf74 c987cefc c987c000 c0221194 dfced400 c987cebc
00000000 c0220b0a dfced400 c987cebc 00000000 c013e3af c154ce00 c987cebc
c987cf14 c013e430 c154ce00 c987cebc d24a1001 58465342 00000000 bfeb0fdc
Call Trace:
[<c0221194>] vfs_statvfs+0x34/0x38
[<c0220b0a>] linvfs_statfs+0x28/0x2e
[<c013e3af>] vfs_statfs+0x4b/0x66
[<c013e430>] vfs_statfs64+0x23/0xb2
[<c013e5ea>] sys_statfs64+0x81/0xbf
[<c024fac4>] tty_write+0x179/0x1bc
[<c0111811>] recalc_task_prio+0x93/0x188
[<c0105878>] math_state_restore+0x28/0x42
[<c0103aa1>] sysenter_past_esp+0x52/0x71
Code: 8b 00 c7 45 24 ff 00 00 00 89 c2 0f b6 c8 25 00 ff 0f 00 c1
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
c020ebb4
*pde = 00000000
Oops: 0000 [#4]
CPU: 0
EIP: 0060:[<c020ebb4>] Not tainted
EFLAGS: 00010202 (2.6.8-rc4)
EIP is at xfs_statvfs+0xb6/0xe8
eax: 00000000 ebx: dacae314 ecx: dacae2f4 edx: 00000000
esi: dacae2f4 edi: 00000000 ebp: d27c1ebc esp: d27c1e68
ds: 007b es: 007b ss: 0068
Process df (pid: 7037, threadinfo=d27c1000 task=c64726c0)
Stack: dacae2f4 00000000 d27c1f74 d27c1efc d27c1000 c0221194 dfced400 d27c1ebc
00000000 c0220b0a dfced400 d27c1ebc 00000000 c013e3af c154ce00 d27c1ebc
d27c1f14 c013e430 c154ce00 d27c1ebc d75b8001 58465342 00000000 bfeb0fdc
Call Trace:
[<c0221194>] vfs_statvfs+0x34/0x38
[<c0220b0a>] linvfs_statfs+0x28/0x2e
[<c013e3af>] vfs_statfs+0x4b/0x66
[<c013e430>] vfs_statfs64+0x23/0xb2
[<c013e5ea>] sys_statfs64+0x81/0xbf
[<c024fac4>] tty_write+0x179/0x1bc
[<c0254921>] write_chan+0x0/0x219
[<c024f94b>] tty_write+0x0/0x1bc
[<c01403e9>] vfs_write+0xc9/0x119
[<c014050a>] sys_write+0x51/0x80
[<c0103aa1>] sysenter_past_esp+0x52/0x71
Code: 8b 00 c7 45 24 ff 00 00 00 89 c2 0f b6 c8 25 00 ff 0f 00 c1
[...]
XFS keeps segfaulting and dying in my machine. It is so strange...
General data:
x86 P-IV 2.5 GHz
512 MB RAM
The filesystem was onto a MAXTOR 70 GB SCSI disk, connected to Adaptec AIC79XX
PCI-X SCSI card. The other filesystem containing files over XFS is a RAID0
over two identical IDE disks.
If you need further information, like .config or so, please do not hesitate
to ask.
Thanks in advance,
Ender.
--
Why is a cow? Mu. (Ommmmmmmmmm)
next reply other threads:[~2004-08-18 16:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-18 16:16 David Martinez Moreno [this message]
2004-08-19 8:44 ` Crashes and lockups in XFS filesystem (2.6.8-rc4) Nathan Scott
2004-08-19 8:39 ` David Martínez Moreno
2004-08-19 17:35 ` Random crashes (was Re: Crashes and lockups in XFS filesystem (2.6.8-rc4).) David Martinez Moreno
[not found] ` <200408192127.58996.ender@debian.org>
2004-08-20 8:47 ` Crashes and lockups in XFS filesystem (2.6.8-rc4 and 2.6.8.1-mm2) Nathan Scott
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=200408181816.57940.ender@debian.org \
--to=ender@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nathans@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox