Red Hat Bugzilla – Bug 229948
nautilus hangs on nfs4 mounts with kernel-2.6.19*
Last modified: 2007-11-30 17:11:57 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):
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:
BUG: unable to handle kernel NULL pointer dereference at virtual address
*pde = 00000000
Oops: 0000 [#1]
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
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
Stack: c17f08b8 ecfbd2e8 00000004 00000000 f15383f0 c0439965 dbee9e00
f1b414b0 f094f610 c062597d c0431551 ecfbd280 f094f758 f1b414b0
f094f758 f9153f17 f1b41400 00000000 ecfbd280 f916128c f1b41400
[<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]
[<f9154a61>] nfs_kill_super+0xc/0x14 [nfs]
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
The contents will appear in the nautilus window and no kernel error will occur
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.
Does a more recent 2.6.20 kernel work?
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.