Bug 229948 - nautilus hangs on nfs4 mounts with kernel-2.6.19*
nautilus hangs on nfs4 mounts with kernel-2.6.19*
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-24 16:14 EST by Anthony Messina
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-30 19:13:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Anthony Messina 2007-02-24 16:14:45 EST
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 18:25:06 EDT
Does a more recent 2.6.20 kernel work?
Comment 2 Anthony Messina 2007-03-30 19:13:52 EDT
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.