[quantal] Kernel oops with NFS mount

[Paweł Stołowski]

I'm experiencing kernel oopses on quantal box, which mounts 3 nfs shares. I'd say the oops occurs in 7/10 cases on shutdown and occasionaly during normal work.

Here is how I mount the shares in quantal box:

192.168.1.5:/home/pawel/Music /home/pawel/Music nfs defaults 0 1
192.168.1.5:/home/pawel/src /home/pawel/src nfs defaults 0 1
192.168.1.5:/home/pawel/unity /home/pawel/unity nfs defaults 0 1

and this is my /etc/exports on the other box:

/home/pawel/src 192.168.1.0/24(rw,no_root_squash,no_subtree_check)
/home/pawel/unity 192.168.1.0/24(rw,no_subtree_check)
/home/pawel/Music 192.168.1.0/24(ro,no_subtree_check)

Attaching a screenshot (stacktrace on shutdown).

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-generic 3.5.0.12.12
ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1
Uname: Linux 3.5.0-10-generic x86_64
ApportVersion: 2.5.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: pawel 1923 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory: 'iw'
Date: Mon Aug 27 14:19:35 2012
HibernationDevice: RESUME=UUID=b7233f22-52f6-46f6-a88b-9a37399a0147
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120820)
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.5.0-10-generic root=UUID=6ad4e111-d23a-4922-a5ae-1a2d8bb6b9e9 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.5.0-10-generic N/A
 linux-backports-modules-3.5.0-10-generic N/A
 linux-firmware 1.90
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/08/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETC7WW (2.27 )
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETC7WW(2.27):bd04/08/2010:svnLENOVO:pn:pvrThinkPadT61:rvnLENOVO:rn:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.version: ThinkPad T61
dmi.sys.vendor: LENOVO

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/

[Paweł Stołowski (stolowski)]

Hi Joseph, I've been running v3.6-rc3-quantal for around 8 hours today and used NFS extensively with no issues, so it looks like the problem is fixed in newer kernels. There was one notable difference in my setup for this test - I was using vesa xorg driver rather than nouveau, as stock quantal nouveau didn't play well with v3.6-rc3; hopefully that didn't matter for the test.

Updated tags per your request.

[Joseph Salisbury (jsalisbury)]

Can you boot back into the original Quantal kernel, but keep the vesa xorg driver, just to confirm the bug comes back.

If it does, we can perform a reverse kernel bisect to identify the commit that fixes this upstream.

[Paweł Stołowski (stolowski)]

Confirming oops with original Quantal kernel.

I think this commit looks related - "Fix Oopses in the NFSv4 idmapper" -
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6dbb35b0a74b44b2a48a5373d48074c5aa69fdf5
(it went into 3.6-rc1). If you look at my oops screenshot, there are nfs_idmap_request / nfs_idmap_lookup calls there.

[TJ (tj)]

Kernel 3.5.4 contains the fixes:

Bryan Schumaker (2):
      NFS: Clear key construction data if the idmap upcall fails
      NFS: return -ENOKEY when the upcall fails to map the name

It is available in "v3.5.4-quantal" or later in the kernel-team's PPA at:

http://kernel.ubuntu.com/~kernel-ppa/mainline/

For installation instructions see:

https://wiki.ubuntu.com/Kernel/MainlineBuilds#Installing_Mainline_Kernels

[Joseph Salisbury (jsalisbury)]

@Pawel,

The Quantal kernel has been rebased to v3.5.4. Can you upgrade to the latest kernel and report back if this bug is fixed?

[CSRedRat (csredrat)]

When Quantal kernel has been rebased to v3.6.0?

[Paweł Stołowski (stolowski)]

@TJ and @Joseph: I've been testing v3.5.4 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.4-quantal/) for last couple of days with no kernel panics. Is this enough for the test, or do I need to also check with latest official 3.5.0 available in Q?

[Joseph Salisbury (jsalisbury)]

It would be best to test the official Quantal kernel - 3.5.0-16

[Alex Bachmeier (cebalrai)]

I'm also seeing bug on an up to date qunatal with kernel 3.5.0-17.
What can I provide to help get this fixed?

[Joseph Salisbury (jsalisbury)]

@Pawel

Were you able to test the latest Quantal kernel?

If Pawel reports it is resolved, you may be running into another bug, Alex. If that is the case, you may want to open a new bug, so we can review it separately.

[Paweł Stołowski (stolowski)]

@Joseph Yes, I don't have problems with 3.5.0-17.