On Fri, Sep 28, 2012 at 09:21:26AM -0400, Bryan Schumaker wrote:
> On 09/28/2012 08:17 AM, Joerg Roedel wrote:
> Maybe it's mounting over v3 now? Can you retry using "vers=4" in your mount
> options?
Tried that, mounting fails with 'No such file or directory'.
Joerg
--
AMD
On 09/28/2012 08:17 AM, Joerg Roedel wrote:
> On Thu, Sep 27, 2012 at 02:15:21PM -0400, Bryan Schumaker wrote:
>
>> Double check that you're using the legacy idmapper, and not the
>> keyring based one (/etc/request-key.conf shouldn't have the "create
>> id_resolver * * /usr/bin/nfsidmap %k %d"
On Thu, Sep 27, 2012 at 02:15:21PM -0400, Bryan Schumaker wrote:
> Double check that you're using the legacy idmapper, and not the
> keyring based one (/etc/request-key.conf shouldn't have the "create
> id_resolver * * /usr/bin/nfsidmap %k %d" line).
That should only be relevant for NFSv4, no? I
On Thu, Sep 27, 2012 at 02:15:21PM -0400, Bryan Schumaker wrote:
Double check that you're using the legacy idmapper, and not the
keyring based one (/etc/request-key.conf shouldn't have the create
id_resolver * * /usr/bin/nfsidmap %k %d line).
That should only be relevant for NFSv4, no? I am
On 09/28/2012 08:17 AM, Joerg Roedel wrote:
On Thu, Sep 27, 2012 at 02:15:21PM -0400, Bryan Schumaker wrote:
Double check that you're using the legacy idmapper, and not the
keyring based one (/etc/request-key.conf shouldn't have the create
id_resolver * * /usr/bin/nfsidmap %k %d line).
On Fri, Sep 28, 2012 at 09:21:26AM -0400, Bryan Schumaker wrote:
On 09/28/2012 08:17 AM, Joerg Roedel wrote:
Maybe it's mounting over v3 now? Can you retry using vers=4 in your mount
options?
Tried that, mounting fails with 'No such file or directory'.
Joerg
--
AMD Operating
On Thu, 2012-09-27 at 09:59 -0700, Linus Torvalds wrote:
> On Thu, Sep 27, 2012 at 9:16 AM, Myklebust, Trond
> wrote:
> >
> > I cannot see how that BUG_ON can be triggered in the current code, given
> > that the only place where idmap->idmap_key_cons is set to a non-NULL
> > value is covered by a
On 09/27/2012 01:56 PM, Joerg Roedel wrote:
> On Thu, Sep 27, 2012 at 04:16:25PM +, Myklebust, Trond wrote:
>>> Yes, it contains that commit. I was about to test plain v3.6-rc7 without
>>> my patches (not nfs related, of cource) on-top, but unfortunatly the
>>> disk with the root-fs died :-/
On Thu, Sep 27, 2012 at 04:16:25PM +, Myklebust, Trond wrote:
> > Yes, it contains that commit. I was about to test plain v3.6-rc7 without
> > my patches (not nfs related, of cource) on-top, but unfortunatly the
> > disk with the root-fs died :-/
> > I am about to set up the box again and test
On Thu, Sep 27, 2012 at 9:16 AM, Myklebust, Trond
wrote:
>
> I cannot see how that BUG_ON can be triggered in the current code, given
> that the only place where idmap->idmap_key_cons is set to a non-NULL
> value is covered by a mutex, and that it is always cleared before we
> release said mutex.
On Thu, 2012-09-27 at 17:39 +0200, Joerg Roedel wrote:
> On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
>
> > Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
> > Clear key construction data if the idmap upcall fails)? The latter was
> > merged in3.6-rc3, and
On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
> Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
> Clear key construction data if the idmap upcall fails)? The latter was
> merged in3.6-rc3, and is reported to fix the problem for the other
> testers.
Yes, it
gt;
> > [ 20.271810] ----[ cut here ]--------
> > [ 20.276869] kernel BUG at
> /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
> > [ 20.284306] invalid opcode: [#1] SMP
> > [ 20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache lockd sunrpc
> kvm_i
el BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
> [ 20.284306] invalid opcode: [#1] SMP
> [ 20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache lockd sunrpc
> kvm_intel radeon kvm ttm drm_kms_helper i7core_edac drm edac_core joydev
> hpilo psmouse hid_generic i2
/linux.trees.git/fs/nfs/idmap.c:681!
[ 20.284306] invalid opcode: [#1] SMP
[ 20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache lockd sunrpc
kvm_intel radeon kvm ttm drm_kms_helper i7core_edac drm edac_core joydev
hpilo psmouse hid_generic i2c_algo_bit serio_raw usbhid hid bnx2
]
[ 20.276869] kernel BUG at
/data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
[ 20.284306] invalid opcode: [#1] SMP
[ 20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache lockd sunrpc
kvm_intel radeon kvm ttm drm_kms_helper i7core_edac drm edac_core
joydev hpilo psmouse hid_generic
On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
Clear key construction data if the idmap upcall fails)? The latter was
merged in3.6-rc3, and is reported to fix the problem for the other
testers.
Yes, it
On Thu, 2012-09-27 at 17:39 +0200, Joerg Roedel wrote:
On Thu, Sep 27, 2012 at 03:32:02PM +, Myklebust, Trond wrote:
Does your checked out copy of 3.6-rc7 contain commit c50669 (NFS:
Clear key construction data if the idmap upcall fails)? The latter was
merged in3.6-rc3, and is
On Thu, Sep 27, 2012 at 9:16 AM, Myklebust, Trond
trond.mykleb...@netapp.com wrote:
I cannot see how that BUG_ON can be triggered in the current code, given
that the only place where idmap-idmap_key_cons is set to a non-NULL
value is covered by a mutex, and that it is always cleared before we
On Thu, Sep 27, 2012 at 04:16:25PM +, Myklebust, Trond wrote:
Yes, it contains that commit. I was about to test plain v3.6-rc7 without
my patches (not nfs related, of cource) on-top, but unfortunatly the
disk with the root-fs died :-/
I am about to set up the box again and test plain
On 09/27/2012 01:56 PM, Joerg Roedel wrote:
On Thu, Sep 27, 2012 at 04:16:25PM +, Myklebust, Trond wrote:
Yes, it contains that commit. I was about to test plain v3.6-rc7 without
my patches (not nfs related, of cource) on-top, but unfortunatly the
disk with the root-fs died :-/
I am about
On Thu, 2012-09-27 at 09:59 -0700, Linus Torvalds wrote:
On Thu, Sep 27, 2012 at 9:16 AM, Myklebust, Trond
trond.mykleb...@netapp.com wrote:
I cannot see how that BUG_ON can be triggered in the current code, given
that the only place where idmap-idmap_key_cons is set to a non-NULL
value
On Tue, 2012-08-07 at 16:50 +0200, Joerg Roedel wrote:
> On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
> > Your stack trace is showing v4 calls on the failing box, those
> > definitely shouldn't be happening if you're using v3. Can you double
> > check /etc/fstab and
On 08/07/2012 11:14 AM, Myklebust, Trond wrote:
> On Tue, 2012-08-07 at 10:36 -0400, Bryan Schumaker wrote:
>> On 08/07/2012 10:27 AM, Joerg Roedel wrote:
>>> On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
> Yes, it reproduces
On Tue, 2012-08-07 at 10:36 -0400, Bryan Schumaker wrote:
> On 08/07/2012 10:27 AM, Joerg Roedel wrote:
> > On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
> >> On 08/07/2012 10:15 AM, Joerg Roedel wrote:
> >>> Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
On 08/07/2012 10:50 AM, Joerg Roedel wrote:
> On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
>> Your stack trace is showing v4 calls on the failing box, those
>> definitely shouldn't be happening if you're using v3. Can you double
>> check /etc/fstab and /proc/mounts on a
On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
> Your stack trace is showing v4 calls on the failing box, those
> definitely shouldn't be happening if you're using v3. Can you double
> check /etc/fstab and /proc/mounts on a working kernel to be sure?
So the bug is probably (for
On 08/07/2012 10:27 AM, Joerg Roedel wrote:
> On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
>> On 08/07/2012 10:15 AM, Joerg Roedel wrote:
>>> Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
>>> Intel box with an NFSv3 directory mounted at boot. This is
On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
> On 08/07/2012 10:15 AM, Joerg Roedel wrote:
> > Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
> > Intel box with an NFSv3 directory mounted at boot. This is the only box
> > I have seen this so far,
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
> On Tue, Aug 07, 2012 at 09:55:14AM -0400, Bryan Schumaker wrote:
>> On 08/07/2012 09:41 AM, Joerg Roedel wrote:
>>> starting with Linux 3.6-rc1 I experience this BUG on one of my test
>>> machines. Please let me know if you need any additional
a reproducer for this? I haven't been able to trigger it on my own :(.
- Bryan
>
> [ 20.271810] [ cut here ]
> [ 20.276869] kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
> [ 20.284306] invalid opcode: [#1] SMP
> [ 20.288806] Modules link
Hi,
starting with Linux 3.6-rc1 I experience this BUG on one of my test
machines. Please let me know if you need any additional information.
[ 20.271810] [ cut here ]
[ 20.276869] kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
[ 20.284306] invalid
Hi,
starting with Linux 3.6-rc1 I experience this BUG on one of my test
machines. Please let me know if you need any additional information.
[ 20.271810] [ cut here ]
[ 20.276869] kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
[ 20.284306] invalid
haven't been able to trigger it on my own :(.
- Bryan
[ 20.271810] [ cut here ]
[ 20.276869] kernel BUG at /data/lemmy/linux.trees.git/fs/nfs/idmap.c:681!
[ 20.284306] invalid opcode: [#1] SMP
[ 20.288806] Modules linked in: nfs4 auth_rpcgss nfs fscache
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 09:55:14AM -0400, Bryan Schumaker wrote:
On 08/07/2012 09:41 AM, Joerg Roedel wrote:
starting with Linux 3.6-rc1 I experience this BUG on one of my test
machines. Please let me know if you need any additional information.
I
On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
Intel box with an NFSv3 directory mounted at boot. This is the only box
I have seen this so far, probably it
On 08/07/2012 10:27 AM, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
Intel box with an NFSv3 directory mounted at boot. This is the only
On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
Your stack trace is showing v4 calls on the failing box, those
definitely shouldn't be happening if you're using v3. Can you double
check /etc/fstab and /proc/mounts on a working kernel to be sure?
So the bug is probably (for
On 08/07/2012 10:50 AM, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
Your stack trace is showing v4 calls on the failing box, those
definitely shouldn't be happening if you're using v3. Can you double
check /etc/fstab and /proc/mounts on a working
On Tue, 2012-08-07 at 10:36 -0400, Bryan Schumaker wrote:
On 08/07/2012 10:27 AM, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
Yes, it reproduces pretty reliable here with Ubuntu 11.10 Server on an
Intel
On 08/07/2012 11:14 AM, Myklebust, Trond wrote:
On Tue, 2012-08-07 at 10:36 -0400, Bryan Schumaker wrote:
On 08/07/2012 10:27 AM, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 10:17:33AM -0400, Bryan Schumaker wrote:
On 08/07/2012 10:15 AM, Joerg Roedel wrote:
Yes, it reproduces pretty reliable
On Tue, 2012-08-07 at 16:50 +0200, Joerg Roedel wrote:
On Tue, Aug 07, 2012 at 10:36:31AM -0400, Bryan Schumaker wrote:
Your stack trace is showing v4 calls on the failing box, those
definitely shouldn't be happening if you're using v3. Can you double
check /etc/fstab and /proc/mounts on a
42 matches
Mail list logo
