| To: | "Ralf Baechle" <ralf@linux-mips.org> |
|---|---|
| Subject: | RE: "exportfs -a" -> stale NFS filehandle |
| From: | "Kaz Kylheku" <kaz@zeugmasystems.com> |
| Date: | Thu, 15 Nov 2007 11:26:06 -0800 |
| Cc: | <linux-mips@linux-mips.org> |
| In-reply-to: | <DDFD17CC94A9BD49A82147DDF7D545C54DC88F@exchange.ZeugmaSystems.local> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| Sender: | linux-mips-bounce@linux-mips.org |
| Thread-index: | AcgnIWkmLMP+TSx6QLCshZmhN5OBlAAlI6RAAABvm/A= |
| Thread-topic: | "exportfs -a" -> stale NFS filehandle |
linux-mips-bounce@linux-mips.org wrote: > Ralf Baechle wrote: >> Can you test below patch? >> >> Ralf > > [ snip ] > >> - PTR sys_nfsservctl >> + PTR compat_sys_nfsservctl > > That's damn funny! ... but it doesn't work. Now the slave systems won't even boot at all. Looking up port of RPC 100003/2 on 127.3.0.1 Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/1 on 127.3.0.1 Root-NFS: Server returned error -13 while mounting /cf2 Ah, but the reason for /that/ is that I have an n32 patch against nfsutils in user space already, which has to be backed out. After backing out the nfsutils patch, the diskless node does boot. However, the original "exportfs -a" problem comes back! So this problem is not resolved simply by using the correct compat routine; it's deeper. Sigh. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: "exportfs -a" -> stale NFS filehandle, Kaz Kylheku |
|---|---|
| Next by Date: | Re: gdb chokes on core from 64-bit kernel (patch), Andrew Sharp |
| Previous by Thread: | RE: "exportfs -a" -> stale NFS filehandle, Kaz Kylheku |
| Next by Thread: | Re: "exportfs -a" -> stale NFS filehandle, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |