Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?
Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.5 kernel[0]. 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'. 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/v4.5-wily/ ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1559563 Title: Kernel Oops - unable to handle kernel paging request at fffffffffffffff8; EIP is at gss_wrap_req_priv.isra.10+0x183/0x2d0 Status in linux package in Ubuntu: Incomplete Bug description: This is a kernel oops that appears to occur under heavy load. Unfortunately, it is not easy to reproduce, and I haven't been able to isolate whether it's associated with NFS load, CPU load, both, or neither. (NFS appears to be relevant, I'm using NFS4 with Kerberos in krb5p, and the oops is in GSS code. I am not using Kerberos for login or other features.) The oops output is attached. Nothing occurs in the console output for hours before it, and I suspect the second oops is related to the first one in some way. Shortly afterward, soft lockups on all other cores (including those on a physically separate processor) make the computer unresponsive. The issue appears to be in net/sunrpc/auth_gss/auth_gss.c's gss_wrap_req_priv, in the following line: tmp = page_address(rqstp->rq_enc_pages[rqstp->rq_enc_pages_num - 1]); It appears that rqstp is set, but both rqstp->rq_enc_Pages and rqstp->rq_enc_pages_num are zero, leading the kernel to attempt dereferencing an invalid address. Because this surfaces only under load, and is on a multiple-processor system, I'm inclined to guess there is a race condition between accesses to rqstp on different cores, but I haven't been able to determine where at this point. Unfortunately, /proc/version_signature isn't currently available as the computer got updated to a 3.13.0-77-generic upon restart, but this was running on a stock "3.13.0-76-generic #120-Ubuntu" kernel on 14.04/trusty. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1559563/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
