From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja; rv:1.8.0.6) Gecko/20060906 Fedora/1.5.0.6-11 Firefox/1.5.0.6 pango-text Description of problem: When I unmount a reiserfs partition by using nautilus, I get a Kernel Bug message. I just connected my USB-HDD which was formatted by reiserfs. The nautilus mounted it automatically. After that, I chose "unmount" command from the popup memu. Version-Release number of selected component (if applicable): kernel-2.6.17-1.2630.fc6 How reproducible: Always Steps to Reproduce: 1.mount a reiserfs partition 2.unmount a reiserfs partition Actual Results: I got a kernel bug message (with stack dump). I added this message in the Additional Information BOX. Expected Results: Additional info: ReiserFS: sda1: using ordered data mode ReiserFS: sda1: journal params: device sda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: sda1: checking transaction log (sda1) ReiserFS: sda1: replayed 3 transactions in 1 seconds ReiserFS: sda1: Using r5 hash to sort names BUG: Dentry c6012d40{i=3,n=.reiserfs_priv} still in use (1) [unmount of reiserfs sda1] ------------[ cut here ]------------ kernel BUG at fs/dcache.c:615! invalid opcode: 0000 [#1] SMP last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_cur_freq Modules linked in: vfat fat reiserfs sd_mod sg usb_storage scsi_mod i915 drm cpufreq_ondemand dm_mirror dm_mod video sbs i2c_ec i2c_core button battery asus_acpi ac ipv6 parport_pc lp parport snd_intel8x0 e100 bcm43xx snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_seq_dummy ohci1394 snd_seq_oss snd_seq_midi_event ieee80211softmac snd_seq snd_seq_device ieee80211 snd_pcm_oss ieee80211_crypt ieee1394 mii pcspkr snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc ide_cd cdrom serio_raw ext3 jbd ehci_hcd ohci_hcd uhci_hcd CPU: 0 EIP: 0060:[<c0487e6e>] Not tainted VLI EFLAGS: 00010246 (2.6.17-1.2630.fc6 #1) EIP is at shrink_dcache_for_umount_subtree+0x146/0x1d7 eax: 0000005a ebx: c6012d40 ecx: 00000008 edx: d2a25eb8 esi: 00000001 edi: c6fbc42c ebp: d2a25ee0 esp: d2a25eb4 ds: 007b es: 007b ss: 0068 Process umount (pid: 3489, ti=d2a25000 task=d2ff8030 task.ti=d2a25000) Stack: c063c2e5 c6012d40 00000003 c6012dbc 00000001 f06163a8 c6fbc42c 00000003 c6fbc1fc f062a360 00000000 d2a25eec c0488919 c6fbc1fc d2a25efc c0478ece c5e80344 c6fbc1fc d2a25f0c c0478fb4 c6fbc1fc f062a320 d2a25f1c c0479074 Call Trace: [<c0488919>] shrink_dcache_for_umount+0x31/0x3e [<c0478ece>] generic_shutdown_super+0x19/0xdf [<c0478fb4>] kill_block_super+0x20/0x32 [<c0479074>] deactivate_super+0x5d/0x6f [<c048be85>] mntput_no_expire+0x42/0x72 [<c047eacf>] path_release_on_umount+0x15/0x18 [<c048cfb1>] sys_umount+0x1e7/0x21b [<c048cff2>] sys_oldumount+0xd/0xf [<c0403faf>] syscall_call+0x7/0xb DWARF2 unwinder stuck at syscall_call+0x7/0xb Leftover inexact backtrace: [<c0405391>] show_stack_log_lvl+0x8a/0x95 [<c04054c9>] show_registers+0x12d/0x19a [<c04056c6>] die+0x190/0x293 [<c06146c2>] do_trap+0x7c/0x96 [<c0405eb6>] do_invalid_op+0x89/0x93 [<c0404be1>] error_code+0x39/0x40 [<c0488919>] shrink_dcache_for_umount+0x31/0x3e [<c0478ece>] generic_shutdown_super+0x19/0xdf [<c0478fb4>] kill_block_super+0x20/0x32 [<c0479074>] deactivate_super+0x5d/0x6f [<c048be85>] mntput_no_expire+0x42/0x72 [<c047eacf>] path_release_on_umount+0x15/0x18 [<c048cfb1>] sys_umount+0x1e7/0x21b [<c048cff2>] sys_oldumount+0xd/0xf [<c0403faf>] syscall_call+0x7/0xb Code: 02 00 00 8b 40 1c 85 d2 8b 00 c7 45 f0 00 00 00 00 74 06 8b 52 20 89 55 f0 57 50 56 51 ff 75 f0 53 68 e5 c2 63 c0 e8 74 d0 f9 ff <0f> 0b 67 02 d9 c2 63 c0 83 c4 1c 8b 73 30 39 de 75 04 31 f6 eb EIP: [<c0487e6e>] shrink_dcache_for_umount_subtree+0x146/0x1d7 SS:ESP 0068:d2a25eb4
I can confirm this bug. Very annoying...
*** Bug 203323 has been marked as a duplicate of this bug. ***
*** Bug 206569 has been marked as a duplicate of this bug. ***
*** Bug 206541 has been marked as a duplicate of this bug. ***
*** Bug 206741 has been marked as a duplicate of this bug. ***
*** Bug 204682 has been marked as a duplicate of this bug. ***
Same thing here, just to confirm: <5>ReiserFS: hde6: found reiserfs format "3.6" with standard journal <5>ReiserFS: hde6: using ordered data mode <5>ReiserFS: hde6: journal params: device hde6, size 8192, journal first block 18, max trans len 1024, max batch 900, max co mmit age 30, max trans age 30 <5>ReiserFS: hde6: checking transaction log (hde6) <5>ReiserFS: hde6: Using r5 hash to sort names <6>SELinux: initialized (dev hde6, type reiserfs), uses genfs_contexts <5>ReiserFS: hde10: found reiserfs format "3.6" with standard journal <5>ReiserFS: hde10: using ordered data mode <5>ReiserFS: hde10: journal params: device hde10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 <5>ReiserFS: hde10: checking transaction log (hde10) <5>ReiserFS: hde10: replayed 2 transactions in 0 seconds <5>ReiserFS: hde10: Using r5 hash to sort names <6>SELinux: initialized (dev hde10, type reiserfs), uses genfs_contexts <3>BUG: Dentry f6529e5c{i=3,n=.reiserfs_priv} still in use (1) [unmount of reiserfs hde10] <0>------------[ cut here ]------------ <0>kernel BUG at fs/dcache.c:615! <0>invalid opcode: 0000 [#1] <1>last sysfs file: /class/scsi_host/host0/proc_name <4>Modules linked in: dm_emc dm_round_robin dm_multipath dm_snapshot dm_mirror dm_zero dm_mod xfs jfs reiserfs lock_nolock g fs2 ext3 jbd msdos raid456 xor raid1 raid0 8139too mii usb_storage uhci_hcd iscsi_tcp libiscsi scsi_transport_iscsi sr_mod s d_mod scsi_mod ide_cd cdrom ipv6 squashfs pcspkr edd floppy loop nfs nfs_acl fscache lockd sunrpc vfat fat cramfs <0>CPU: 0 <4>EIP: 0060:[<c0473678>] Not tainted VLI <4>EFLAGS: 00010246 (2.6.17-1.2630.fc6 #1) <0>EIP is at shrink_dcache_for_umount_subtree+0x146/0x1d6 <0>eax: 0000005b ebx: f6529e5c ecx: f6b92eb8 edx: c06175d5 <0>esi: 00000001 edi: f6b0cd0c ebp: f6b92ee0 esp: f6b92eb4 <0>ds: 007b es: 007b ss: 0068 <0>Process umount (pid: 643, ti=f6b92000 task=dfe2cac0 task.ti=f6b92000) <0>Stack: c06175d5 f6529e5c 00000003 f6529ee4 00000001 f8b82088 f6b0cd0c 00000003 <0> f6b0ca94 f8b95a80 00000000 f6b92eec c0474128 f6b0ca94 f6b92efc c0464ae8 <0> f6b05aec f6b0ca94 f6b92f0c c0464bc2 f6b0ca94 f8b95a40 f6b92f1c c0464c82 <0>Call Trace: <4> [<c0474128>] shrink_dcache_for_umount+0x30/0x3d <4> [<c0464ae8>] generic_shutdown_super+0x19/0xd3 <4> [<c0464bc2>] kill_block_super+0x20/0x32 <4> [<c0464c82>] deactivate_super+0x5d/0x6f <4> [<c04775f7>] mntput_no_expire+0x42/0x71 <4> [<c046a4ba>] path_release_on_umount+0x15/0x18 <4> [<c0478707>] sys_umount+0x1d3/0x207 <4> [<c0478748>] sys_oldumount+0xd/0xf <4> [<c0402e57>] syscall_call+0x7/0xb <4>DWARF2 unwinder stuck at syscall_call+0x7/0xb <4>Leftover inexact backtrace: <4> [<c040397e>] show_stack_log_lvl+0x8a/0x95 <4> [<c0403aae>] show_registers+0x125/0x192 <4> [<c0403c7a>] die+0x15f/0x262 <4> [<c05f53e6>] do_trap+0x7c/0x96 <4> [<c040439f>] do_invalid_op+0x89/0x93 <4> [<c0403179>] error_code+0x39/0x40 <4> [<c0474128>] shrink_dcache_for_umount+0x30/0x3d <4> [<c0464ae8>] generic_shutdown_super+0x19/0xd3 <4> [<c0464bc2>] kill_block_super+0x20/0x32 <4> [<c0464c82>] deactivate_super+0x5d/0x6f <4> [<c04775f7>] mntput_no_expire+0x42/0x71 <4> [<c046a4ba>] path_release_on_umount+0x15/0x18 <4> [<c0478707>] sys_umount+0x1d3/0x207 <4> [<c0478748>] sys_oldumount+0xd/0xf <4> [<c0402e57>] syscall_call+0x7/0xb <0>Code: 02 00 00 8b 40 1c 85 d2 8b 00 c7 45 f0 00 00 00 00 74 06 8b 52 20 89 55 f0 57 50 56 51 ff 75 f0 53 68 d5 75 61 c0 e 8 a1 33 fa ff <0f> 0b 67 02 c9 75 61 c0 83 c4 1c 8b 73 3c 39 de 75 04 31 f6 eb <0>EIP: [<c0473678>] shrink_dcache_for_umount_subtree+0x146/0x1d6 SS:ESP 0068:f6b92eb4 <4>
*** Bug 206831 has been marked as a duplicate of this bug. ***
*** Bug 206857 has been marked as a duplicate of this bug. ***
http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1220.html This seems to look promising (and has a patch even).
*** Bug 206974 has been marked as a duplicate of this bug. ***
Can confirm that the bug still exists in FC6T3. Because, Anaconda installer probes all partitions (for perhaps to provide a upgrade option whatever), FC6(T3) can't be installed on a machine with preexisting Reiser file systems. Is there a parameter that can be passed during bootup to not probe Reiser file systems (or disabling reiserfs.ko kernel module) somehow & at the same time continuing with the installation/upgrade process until this bug is fixed? My work-around of "rmmod reiserfs" from the console before proceeding with the welcome screen is very ugly indeed :-(. I think this exposes some other bug in Anaconda that results in Anaconda not recognising valid FC5 installation on ext3 file systems. I think it'd be good to upgrade an FC5 (or 4 whatever) system on a drive that coincidentally has Reiser file system(s). I'm afraid this is going to be a show stopper for FC6 (I know many friends & computers with Reiser file system(s)). Thanks
Whoops, Anaconda does recognise valid FC5 installation on ext3 file system(s) after manually unloading reiserfs kernel module. I apologise for that misinformation. Thanks
How can we manually unload reiserfs and xfs module? Thanks.
To Igor's question above: By executing "rmmod reiserfs" & "rmmod xfs" as the root account from the virtual console (eg, Ctrl + Alt + F2). If you don't want those kernel modules loaded while the GUI Installer is running, then remove the modules before continuing on with the very first GUI screen (welcome screen?). To disable the modules permanently after the installation, pls ref to man 5 modprobe.conf :-) [Alternatively, rename the respective kernel modules, eg /lib/modules/2.6.18-whatever/kernel/fs/(reiserfs|xfs)/(reiserfs|xfs).ko to something else. This is a very ugly thing to do, cos the problem is truly in the kernel space. Also, you might upset package mgmt tools - rpm/dpkg etc.] Thanks
I knew about modprobe.conf (5) and modprobe (8) , but It didn't occured to me that I can access to virtual console while Anaconda is running :) Thanks, it did work! Cheers!
I knew about modprobe.conf (5) and modprobe (8) , but It didn't occured to me that I can access to the virtual console while Anaconda is running :) Thanks, it did work! Cheers!
(In reply to comment #10) > http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1220.html > > This seems to look promising (and has a patch even). It seems same problem. I'll check that patch. Thanks!
(In reply to comment #18) > (In reply to comment #10) > > http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1220.html > > > > This seems to look promising (and has a patch even). > > It seems same problem. I'll check that patch. I applied that patch to the kernel-2.6.17-1.2647.fc6, and tested (unmounted reiserfs partition). I could unmount reiserfs formatted partition safely. Thanks!
Created attachment 136810 [details] reiser-fs-dentries.patch Since this is confirmed to be the working patch, I'm attaching it here for easier accessibility.
With kernel 2.6.18-1.2689.fc6 (I see it in the release notes that reiserfs patch has been applied), unmounting a reiserfs file system leads to no kernel bug. (Now let's hope this fix will be in FC6 :-)). Thanks
I tested that patch as well, works for me, FWIW.
*** Bug 206714 has been marked as a duplicate of this bug. ***
This patch is in the current builds.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|FIXEDAWAITINGTEST |TESTED ------- Additional Comments From marksmit.com 2006-10-03 20:52 EDT ------- I successfully verified this fix in the Oct3 snapshot of rawhide on power5 hw: 1. installed sayerslp1, virtual eth, vscsi disks sda, sdab with opensuse10.2 alpha4, choosing defaults which created a reiserfs. 2. netbooted with FC6-test3's ppc64.img and verified recreation. 3. rebooted, netbooted Oct3 version of ppc64.img, and started install from nfs://rhlte/distros/snap (dir of rawhide snapshot). Problem is fixed; no recreate.