Bug 229948
| Summary: | nautilus hangs on nfs4 mounts with kernel-2.6.19* | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Anthony Messina <amessina> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6 | CC: | wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-03-30 23:13:52 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Does a more recent 2.6.20 kernel work? 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. |
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.