Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 229948 - nautilus hangs on nfs4 mounts with kernel-2.6.19*
Summary: nautilus hangs on nfs4 mounts with kernel-2.6.19*
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-24 21:14 UTC by Anthony Messina
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-30 23:13:52 UTC


Attachments (Terms of Use)

Description Anthony Messina 2007-02-24 21:14:45 UTC
Description of problem:
I use nfs4 automounts to access servers on my lan.  Occasionally and
unpredictably, when I try to connect to an nfs4 share using nautilus, I get the
 results shown below.  I have also tested if automount is the issue by placing
these chares in /etc/fstab so they are permanently mounted at boot.  The issue
still occurs with the same frequency whether or not I use autofs.  If I roll
back to using kernel 2.6.18-1.2869.fc6, the problem goes away. 

Version-Release number of selected component (if applicable):
kernel 2.6.19-1.2911.fc6
nautilus-2.16.2-7.fc6

How reproducible:
Difficult to determine.  Sometimes it occurs the first time I try to access the
share, sometimes it's not for days after I had been accessing it regularly.

Steps to Reproduce:
1. Create an nfs4 share on another computer; configure either autofs or a mountpoint
2. Open a nautilus window however you like and type in the mountpoint, hit enter
3. Notice the contents sometimes appear, sometimes do not.
4. If they do not, dmesg will show:
  
Actual results:
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000018
printing eip:
f915299c
*pde = 00000000
Oops: 0000 [#1]
SMP 
last sysfs file: /class/net/eth0/carrier
Modules linked in: nfs lockd nfs_acl i915 drm autofs4 hidp rfcomm l2cap
bluetooth sunrpc dm_mirror dm_multipath dm_mod video sbs i2c_ec button
battery asus_acpi ac ipv6 lp joydev snd_intel8x0(F)(U)
snd_ac97_codec(F)(U) snd_ac97_bus snd_seq_dummy(F)(U) snd_seq_oss(F)(U)
snd_seq_midi_event(F)(U) snd_seq(F)(U) snd_seq_device(F)(U)
snd_pcm_oss(F)(U) snd_mixer_oss(F)(U) snd_pcm(F)(U) sg snd_timer(F)(U)
snd(F)(U) i2c_i801 soundcore ide_cd iTCO_wdt snd_page_alloc(F)(U)
i2c_core parport_pc tg3 cdrom parport usblp serio_raw pcspkr usb_storage
ata_piix libata sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    1
EIP:    0060:[<f915299c>]    Tainted: GF     VLI
EFLAGS: 00010246   (2.6.19-1.2911.fc6 #1)
EIP is at nfs_update_inode+0xb0/0x65a [nfs]
eax: 00000000   ebx: 000081b4   ecx: 000081b4   edx: 00008000
esi: ef6c6580   edi: f1b414b0   ebp: f094f758   esp: dbee9de8
ds: 007b   es: 007b   ss: 0068
Process umount.nfs4 (pid: 19406, ti=dbee9000 task=f15383f0
task.ti=dbee9000)
Stack: c17f08b8 ecfbd2e8 00000004 00000000 f15383f0 c0439965 dbee9e00
dbee9e00 
       f1b414b0 f094f610 c062597d c0431551 ecfbd280 f094f758 f1b414b0
f094f7c8 
       f094f758 f9153f17 f1b41400 00000000 ecfbd280 f916128c f1b41400
f29533d0 
Call Trace:
[<f9153f17>] nfs_post_op_update_inode+0x2a/0x39 [nfs]
[<f916128c>] nfs4_proc_delegreturn+0x12c/0x181 [nfs]
[<f916babd>] nfs_do_return_delegation+0xf/0x1d [nfs]
[<f91516e4>] nfs_dentry_iput+0x13/0x3e [nfs]
[<c048482c>] shrink_dcache_for_umount_subtree+0x1c2/0x213
[<c04856c1>] shrink_dcache_for_umount+0x2e/0x3a
[<c04772d8>] generic_shutdown_super+0x19/0xdf
[<c04773d4>] kill_anon_super+0x9/0x30
[<f9154a61>] nfs_kill_super+0xc/0x14 [nfs]
[<c0477469>] deactivate_super+0x57/0x6a
[<c0489172>] expire_mount_list+0xe9/0x120
[<c04891db>] shrink_submounts+0x32/0xad
[<c0489df9>] sys_umount+0xfb/0x22f
[<c0489f44>] sys_oldumount+0x17/0x1a
[<c040404b>] syscall_call+0x7/0xb
[<00754402>] 0x754402
=======================
Code: 20 0f b7 5d 28 89 c8 89 da 25 00 f0 00 00 81 e2 00 f0 00 00 39 c2
0f 85 ac 04 00 00 8b 85 c0 00 00 00 8b b0 a8 01 00 00 8b 40 38 <3b> 68
18 75 52 83 c7 44 89 7c 24 2c 8b 7c 24 20 8d 46 74 89 44 
EIP: [<f915299c>] nfs_update_inode+0xb0/0x65a [nfs] SS:ESP 0068:dbee9de8

Expected results:
The contents will appear in the nautilus window and no kernel error will occur

Additional info:
Once this happens, nautilus becomes uninterruptable and the only way I can
recover is to do a hard reboot.  Interestingly, I also tried mounting with hard
or soft nfs4 parameters which made no difference, but I am still able to use my
computer.  I mean that if one nfs4 share fails, but another one is still working
- say my home directory - I can access files, use Evolution, open Firefox, etc.
in the working share (my home dir in this example), but nautilus won't work.

Comment 1 Chuck Ebbert 2007-03-30 22:25:06 UTC
Does a more recent 2.6.20 kernel work?


Comment 2 Anthony Messina 2007-03-30 23:13:52 UTC
yes.

uname -r
2.6.20-1.2933.fc6

the 2.6.20 kernels seem to work.  i have not seen the bug repeated.  though i
think it may somehow be related to the tg3 driver.  i had previous issues with
the tg3 network driver, though i have no way of supporting that claim.

also, i installed fc6 on another system and have had no issues at all.


Note You need to log in before you can comment on or make changes to this bug.