From: Jan Dittmer <jdi@l4x.org>
To: Linux kernel <linux-kernel@vger.kernel.org>
Subject: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Date: Tue, 07 Feb 2006 21:39:15 +0100 [thread overview]
Message-ID: <43E90573.8040305@l4x.org> (raw)
Debian 2.6.15-1-686-smp
$ umount /mnt/data
Segmentation Fault
dmesg:
VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...
Unable to handle kernel NULL pointer dereference at virtual address 00000034
printing eip:
f88c7e07
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: xfs rfcomm l2cap bluetooth nfsd exportfs lockd nfs_acl sunrpc ipv6 deflate zlib_deflate twofish serpent aes blowfish des sha256
sha1 crypto_n ull af_key raid5 xor dm_mod tun vfat fat loop lp usbmouse eeprom i2c_dev i2c_isa i2c_core usbkbd usb_storage ehci_hcd button processor
ac ide_cd cdrom e100 mii 3w_xxxx e1000 joydev piix serio_raw uhci_hcd generic parport_pc ide_core usbcore parport pcspkr psmouse rtc ext3 jbd mbcache
raid1 md_mod sd_mod aic79xx scsi_tr ansport_spi scsi_mod shpchp pci_hotplug evdev mousedev
CPU: 2
EIP: 0060:[<f88c7e07>] Not tainted VLI
EFLAGS: 00210282 (2.6.15-1-686-smp)
EIP is at ext3_show_options+0x13/0xd5 [ext3]
eax: 00000000 ebx: f7f1fe00 ecx: da82c540 edx: 00000000
esi: da82c540 edi: da82c540 ebp: 00000400 esp: f7bcbf18
ds: 007b es: 007b ss: 0068
Process mv (pid: 4409, threadinfo=f7bca000 task=e9978a70)
Stack: 00000000 dfd74c00 c01646cf da82c540 dfd74c00 da82c540 dfd74c00 00000143
c0167ffd da82c540 dfd74c00 00000000 da82c560 0000000a 00000000 00000009
00000000 00000400 e64cea80 40019000 00000000 c014ca9d e64cea80 40019000
Call Trace:
[<c01646cf>] show_vfsmnt+0xcf/0xe6
[<c0167ffd>] seq_read+0x199/0x26a
[<c014ca9d>] vfs_read+0xa1/0x138
[<c014cd92>] sys_read+0x3b/0x64
[<c010275b>] sysenter_past_esp+0x54/0x75
Code: e8 9c 64 ff ff c7 43 b8 00 00 00 00 59 89 74 24 0c 5b 5e e9 9f 34 87 c7 56 53 8b 44 24 10 8b 74 24 0c 8b 58 14 8b 83 70 01 00 00 <8b> 40 34 25
00 0c 00 00 3d 00 04 00 00 75 07 68 ec 04 8d f8 eb
------------[ cut here ]------------
kernel BUG at include/linux/dcache.h:294!
invalid operand: 0000 [#2]
SMP
Modules linked in: xfs rfcomm l2cap bluetooth nfsd exportfs lockd nfs_acl sunrpc ipv6 deflate zlib_deflate twofish serpent aes blowfish des sha256
sha1 crypto_n ull af_key raid5 xor dm_mod tun vfat fat loop lp usbmouse eeprom i2c_dev i2c_isa i2c_core usbkbd usb_storage ehci_hcd button processor
ac ide_cd cdrom e100 mii 3w_xxxx e1000 joydev piix serio_raw uhci_hcd generic parport_pc ide_core usbcore parport pcspkr psmouse rtc ext3 jbd mbcache
raid1 md_mod sd_mod aic79xx scsi_tr ansport_spi scsi_mod shpchp pci_hotplug evdev mousedev
CPU: 2
EIP: 0060:[<c0158262>] Not tainted VLI
EFLAGS: 00210246 (2.6.15-1-686-smp)
EIP is at __follow_mount+0x4b/0x6d
eax: 00000000 ebx: dfd74c00 ecx: 00000001 edx: f75bed20
esi: 00000000 edi: f79f1ecc ebp: dfea6180 esp: f79f1e6c
ds: 007b es: 007b ss: 0068
Process umount (pid: 4481, threadinfo=f79f0000 task=f7079030)
Stack: f7801690 f79f1f68 f79f1ecc c015837e f79f1ecc b6b2be6c f66e129c db8b0005
f79f1f68 c0158b78 f79f1f68 f79f1ec0 f79f1ecc db8b000b 00000000 c1880c20
00000003 00000000 dfde8f48 dfde8e9c 000000c2 b6b2be6c 00000006 db8b0005
Call Trace:
[<c015837e>] do_lookup+0x3a/0x7c
[<c0158b78>] __link_path_walk+0x7b8/0xbe8
[<c0158ff3>] link_path_walk+0x4b/0xbf
[<c011c2fb>] __do_softirq+0x57/0xc0
[<c0159357>] path_lookup+0x13a/0x142
[<c015955e>] __user_walk+0x23/0x3a
[<c0154c5f>] sys_readlink+0x20/0x91
[<c011c2fb>] __do_softirq+0x57/0xc0
[<c010275b>] sysenter_past_esp+0x54/0x75
Code: 80 00 00 85 f6 58 74 14 8b 07 85 c0 74 0e c7 40 30 00 00 00 00 50 e8 3f c2 00 00 58 89 1f 8b 53 10 85 d2 74 11 8b 02 85 c0 75 08 <0f> 0b 26 01
69 4a 28 c0 f0 ff 02 89 57 04 be 01 00 00 00 8b 47
Filesystem is (was?) ext3 on lvm2 on raid5 on 5 IDE drives on 3ware
controller. Accessing the mount point crashed the machine. Last Words:
http://l4x.org/misc/imgp1483.jpg
After reboot everything back to normal, fsck didn't find any errors.
Right before unmouting I moved around 450gb off from the raid to
another raid on the same controller, so controller seems to be fine and
I don't think that the harddisks fail in such a subtle way, that the
raid consistency isn't affected.
Not reproducable but perhaps helpful or important nevertheless.
Funny message in any case ;-)
Jan
next reply other threads:[~2006-02-07 20:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-07 20:39 Jan Dittmer [this message]
2006-02-08 0:23 ` VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day Andrew Morton
2006-02-08 7:48 ` Jan Dittmer
2006-02-08 18:06 ` Balbir Singh
2006-02-08 22:42 ` Jan Dittmer
2006-02-09 4:02 ` Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2006-12-28 9:27 Jesper Juhl
2006-12-28 9:43 ` Jan Engelhardt
2006-12-28 9:43 ` Jan Engelhardt
2006-12-28 10:32 ` Ian Kent
2006-12-28 10:32 ` Ian Kent
2001-07-29 19:13 David Ford
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=43E90573.8040305@l4x.org \
--to=jdi@l4x.org \
--cc=linux-kernel@vger.kernel.org \
/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.