I'm getting this same issue in kernel 4.4.0-96 on Xenial. Any
suggestions?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1650336
Title:
NFS client : kernel 4.4.0-57 crash with nfsv4 enries in
N.B. that according to the changelog of the 4.4.0-70 kernel package, the
patch has only been applied to -67 (thus effectively to -70)!
Now, can we assess if the forementioned bug will be fixed by this as
well?!?
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Can whoever found the root cause in this case have a look at
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1466654
as well please? It sounds very much related, and is a major issue in our
environment.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
This bug was fixed in the package linux - 4.4.0-65.86
---
linux (4.4.0-65.86) xenial; urgency=low
* linux: 4.4.0-65.86 -proposed tracker (LP: #1667052)
[ Stefan Bader ]
* Upgrade Redpine RS9113 driver to support AP mode (LP: #1665211)
- SAUCE: Redpine driver to support
Looks good,
this bug seems to be solved with the -proposed kernel 4.4.0-65.86 ...
good work ... thank you very much
I changed the tag 'verification-needed-xenial' to 'verification-done-
xenial'
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag
** Changed in: linux (Ubuntu Xenial)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1650336
Title:
NFS client : kernel 4.4.0-57 crash with nfsv4 enries in
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Released
** Changed in: linux (Ubuntu Xenial)
Assignee: Joseph Salisbury (jsalisbury) => Seth Forshee (sforshee)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Description changed:
+ SRU Justification
+
+ Impact: A commit from upstream 4.4 stable introduced a regression in
+ refcounting auth_gss messages which can lead to an oops.
+
+ Fix: Cherry pick upstream commit
+ 1cded9d2974fe4fe339fc0ccd6638b80d465ab2c "SUNRPC: fix refcounting
+ problems
Ok, looks good, i tried several reboots with this kernel and all were
successfull :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1650336
Title:
NFS client : kernel 4.4.0-57 crash with nfsv4
Sorry for the delay. Please test the kernel below to see if it fixes the
problem. It also includes the submount permission fix from the other
bug.
http://people.canonical.com/~sforshee/lp1650336/linux-4.4.0-63.84+lp1650336v201702150737/
--
You received this bug notification because you are a
There were two commits to sunrpc between 4.4.0-38 and 4.4.0-42 which
came from upstream 4.4 stable.
4bb0ea1f3289 SUNRPC: Handle EADDRNOTAVAIL on connection failures
8785a1d6c5b3 SUNRPC: allow for upcalls for same uid but different gss service
There's a later commit which says it fixes problems
Hm, sorry i hope there was no misunderstanding ?!
As i mentioned some times before, there was a strange behaviour when i test the
kernels the first time.
Sometimes a kernel boot successfully for one or two times and crash not before
the third try ...
I could reproduce this behaviour on
So, now i try to formulate a new short bug description with all facts i
know at the moment :
Since kernel version 4.4.0-42 (offical repo for 16.04.1) the boot
process crashed when there are at least two nfsv4 entries to the same
nfs-server in /etc/fstab
With only one share entry in the
@Seth
> Thanks for the clarifications.
Har Har
> Yeah, looks like this build never made it out of our PPA.
Unfortunately, i do not found this kernel versions on one of our computers.
But i am rather sure having seen this kernel in the offical repos
--
You received this bug notification
On Thu, Jan 19, 2017 at 06:14:33PM -, Thomas Fili wrote:
> @Seth : Yes, this problem is very confusing
Thanks for the clarifications.
> Unfortunately the kernel 4.4.0-54 is not available any longer from
> offical repos ... so i not able to test this one again ... but maybe
> this kernel had
@Seth : Yes, this problem is very confusing
Since posting #8 i used a dedicated test system with a fresh kubuntu 16.04.1
installation on a well tested system.
During the testing i modify /etc/fstab switching between noauto/auto options of
nfs shares and later changing server uri to ip address
@Thomas: I've been going back through the test results here and
something isn't making sense. During the bisect you reported that the
kernel built at commit 50f208e18014589971583a8495987194724d56e4 was bad.
This commit has no code changes relative to 4.4.0-54, so they should
behave the same. This
Very stange ...
I test 4.10-rc4 again and found that the kernel is booting without
problems with all shares when using the pure IP address for the server
in /etc/fstab ... it is irrelevant if the correct entry in /etc/hosts
exist or dns resolution is ok.
I dunno why 4.9.4 is working with dns
When you ask if the kernel 4.10-rc4 do not crash any long on boot time,
then i can answer : Yes, the kernel do not crash any longer.
But when you ask if the kernel 4.10-rc4 work as expected with nfs
Then i can answer No, he do not work as expected with nfs shares.
IMHO the mainline kernel 4.9.4
So this bug does not happen with the 4.10-rc4 kernel from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.10-rc4
If that is the case, we can perform a "Reverse" bisect to identify the
commit that resolves that bug upstream.
--
You received this bug notification because you are a member of
Thank you for your effort
Unfortunately the tests are very confusing
With the two shares from the FreeBSD 11 Server the mainline kernel 4.10.0 has
no problem !!!
Also if i try to mount two additional shares from another FreeBSD 11 Server. No
Problem at all !
But if i am try to mount the two
We may have provided an improper "Good" or "Bad" result to the bisect.
We may have to test the previously posted kernels again to confirm test
results.
However, can you first test the latest upstream 4.4 stable kernel and
mainline kernel to see if this bug is already fixed upstream? They can
be
Sorry, the same behavior.
But i found something else...
It is very frustrating, to be apparent the only one having this problem, so i
try to setup a nfsv4 server on Ubuntu (14.04.5 with linux-generic-lts-wily
kernel 4.2.0-42)
/etc/exports:
/home/exports
The bisect reported commit 50f208e18014589971583a8495987194724d56e4 as
the first bad commit. I built a Xenial test kernel with this commit
reverted. It can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1650336/
Can you test this kernel and see if it resolves this bug?
Note, you
No, sorry the kernel crash, too
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1650336
Title:
NFS client : kernel 4.4.0-57 crash with nfsv4 enries in /etc/fstab
To manage notifications about this
I built the next test kernel, up to the following commit:
50f208e18014589971583a8495987194724d56e4
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1650336
Can you test that kernel and report back if it has the bug or not? I
will build the next test kernel based on
Thank you for the test kernel :)
But unfortunately it also crashs at the same position.
Beginns with: BUG: unable to handle kernel paging request at 814121a8
...
The 4.4.41 also crash, as i mention before ... On all computers i tested
i have the same behavior that i can successfully boot
Thanks for finding out the bug does not exist in the upstream 4.8
kernel. There are only a couple more test kernels for the bisect, so we
may as well finish it.
I built the next test kernel, up to the following commit:
4891ae8e5d0801f13739c26300ac4cd162c3e63c
The test kernel can be downloaded
The mainline kernel 4.8.17-040817 do not have the problem, 4.4.41-040441
have the problem
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1650336
Title:
NFS client : kernel 4.4.0-57 crash with nfsv4
I noticed some additional detail ...
The problem only occur if the second nfs share is on the same NFS Server as the
first share.
I tried to mount a second share from another NFSv4 Server, also running under
FreeBSD 11, without problem
--
You received this bug notification because you are a
Sorry, no changes ... but i noticed something that could be usefull.
To ensure there is no hardware problem on my computer, i installed a
fresh kubuntu 16.04.01 on a newer maschine and configured it.
Same behaviour ... the base kernel from installation 4.4.0-31 work without
problem ... but all
I built the next test kernel, up to the following commit:
764d47217b1f3881600e11c08f109b177e521b15
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1650336
Can you test that kernel and report back if it has the bug or not? I
will build the next test kernel based on
Unfortunately no changes ... same behavior ...
But i notice something strange ... if i boot some of this corrupt
kernels that crash and then restart with the Magic SysRQ into a "good"
kernel ...this kernel crashes at the same point.
Another Magic SysRQ or a cold start let boot the "good" kernel
I built the next test kernel, up to the following commit:
ed8c9a98e60fc731a9d83a7a137d5d84210967f5
The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1650336
Can you test that kernel and report back if it has the bug or not? I
will build the next test kernel based on
Thank you for this test kernel.
Unfortunately this one has the same problems like the official 4.4.0-57
Without /etc/fstab or with noauto entries for nfs the kernel boot fine.
With the nfs entries the kernel crashes ... sorry
--
You received this bug notification because you are a member of
I started a kernel bisect between Ubuntu 4.4.0-54 and Ubuntu 4.4.0-57.
The kernel bisect will require testing of about 4-5 test kernels.
I built the first test kernel, up to the following commit:
0cd611da7d4c01b178144bc17da8cd92cae2b1fa
The test kernel can be downloaded from:
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu Xenial)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Joseph Salisbury (jsalisbury)
** Changed in: linux (Ubuntu Xenial)
Assignee:
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Status: New => Confirmed
**
Yes,
in fact it is not possible to execute the apoort-collect command when the
kernel crashed.
If someone need information about the hardware, i can boot the computer
without the nfs stab entry and execute then the command.
But i can also report the same problem from other computers ( for
40 matches
Mail list logo
