Bug#669270: Evolution triggers NFS4 problem

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Russel,

Russel Winder wrote:

> U am using Debian Unstable kept up to date daily.  Whenever I try to
> create a new email using Evolution, the kernel reports on all open
> terminals and Evolution becomes totally unresponsive.
[...]
> the determination is that this is an NFS bug, which given the data
> seems reasonable, hence this report.

Thanks for reporting it.

[...]
> BUG: unable to handle kernel paging request at ffffffffffffffb8
> IP: [<ffffffffa0fdeabd>] nfs_mark_delegation_referenced+0x6/0x6 [nfs]
> PGD 1607067 PUD 1608067 PMD 0 
> Oops: 0000 [#1] SMP 
> CPU 6 
> Modules linked in: ppdev lp mperf cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave rfcomm bnep binfmt_misc xt_limit xt_tcpudp ipt_LOG ipt_MASQUERADE xt_DSCP ipt_REJECT nf_conntrack_irc nf_conntrack_ftp xt_state uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables x_tables loop nvidia(P) btusb snd_emu10k1_synth snd_emux_synth snd_seq_midi_emul snd_seq_virmidi bluetooth snd_emu10k1 snd_util_mem snd_ac97_codec snd_hwdep usb_storage snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi i5400_edac hid_logitech_dj rfkill edac_core uas joydev iTCO_wdt iTCO_vendor_support snd_seq i5k_amb parport_pc snd_seq_device snd_timer rng_core i2c_i801 parport snd soundcore ac97_bus dcdbas button processor shpchp psmouse evdev emu10k1_gp pcspkr gameport serio_raw i2c_core thermal_sys ext4 crc16 jbd2 mbcache usbhid hid sr_mod sd_mod cdrom crc_t10dif ata_generic ata_piix uhci_hcd ahci libahci libata scsi_mod ehci_hcd usbcore tg3 libphy usb_common [last unloaded: scsi_wait_scan]
> 
> Pid: 5305, comm: evolution Tainted: P           O 3.2.0-2-amd64 #1 Dell Inc. Precision WorkStation T5400  /0RW203
> RIP: 0010:[<ffffffffa0fdeabd>]  [<ffffffffa0fdeabd>] nfs_mark_delegation_referenced+0x6/0x6 [nfs]
> RSP: 0018:ffff8801d21e9e50  EFLAGS: 00010246
> RAX: ffff88031f44ec00 RBX: 00000000ffffd8ca RCX: 00000000ffffd8ca
> RDX: ffff8801d21e9eb8 RSI: 0000000000000001 RDI: 0000000000000000
> RBP: ffff8801d21e9eb8 R08: ffff8801d21e8000 R09: ffff88031eebfb18
> R10: ffff88031f5236d0 R11: ffff88031f5236d0 R12: ffff88031ff8a000
> R13: ffff88031f508400 R14: ffff8801d7742180 R15: 0000000000000000
> FS:  00007ffff7fa09c0(0000) GS:ffff88032fd80000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffffffffffffffb8 CR3: 000000030dc3f000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process evolution (pid: 5305, threadinfo ffff8801d21e8000, task ffff88031f5236d0)
> Stack:
>  ffffffffa0fcfcd8 ffff88031eebfb18 ffff8803224dee00 ffff8801d7742180
>  00000000000000fa 0000000000000007 0000000000000082 ffff88031f5236d0
>  ffffffffa0fd1eee ffff88028735cdb8 ffffffffffffd8ca ffff8801d21e9eb8
> Call Trace:
>  [<ffffffffa0fcfcd8>] ? nfs4_handle_exception+0x147/0x2bf [nfs]
>  [<ffffffffa0fd1eee>] ? nfs4_proc_lock+0x2c8/0x324 [nfs]
>  [<ffffffffa0fba964>] ? do_setlk+0x59/0xcc [nfs]
>  [<ffffffffa0fba9d7>] ? do_setlk+0xcc/0xcc [nfs]
>  [<ffffffff8112eb30>] ? sys_flock+0x109/0x134
>  [<ffffffff8134e252>] ? system_call_fastpath+0x16/0x1b
> Code: df e8 a7 4c ff ff 48 89 ef 89 44 24 08 e8 d8 fc ff ff 8b 44 24 08 48 83 c4 38 5b 5d 41 5c 41 5d 41 5e 41 5f c3 f0 80 4f 48 04 c3 <48> 8b 7f b8 31 c0 48 85 ff 74 16 8b 57 30 83 e6 03 21 f2 39 f2 
> RIP  [<ffffffffa0fdeabd>] nfs_mark_delegation_referenced+0x6/0x6 [nfs]
>  RSP <ffff8801d21e9e50>
> CR2: ffffffffffffffb8

Can you reproduce this without the nvidia driver?  (I don't expect it
to be any different, but it will help us get help from upstream.) Is
the first backtrace always the same when this happens?  (It should say
"Not tainted" on the dmesg output line starting with "Pid".)  Does
3.3.2 from experimental behave the same way?

Is this a regression?  What are the newest kernel version that worked
and the oldest that did not work?  Does a squeeze kernel reproduce the
same problem?  (The squeeze kernel packages should install without
trouble on a wheezy/sid system.)

Thanks and hope that helps,
Jonathan