Date: Sun, 5 Mar 2017 11:25:47 +0000 From: Andrew Turner <andrew@fubar.geek.nz> To: =?utf-8?B?T3RhY8OtbGlv?= <otacilio.neto@bsd.com.br> Cc: freebsd-hackers@freebsd.org, rmacklem@freebsd.org Subject: Re: Simple program immediately killed when running on a NFS Message-ID: <1E759624-BA9B-4039-8E70-711D7435EB4B@fubar.geek.nz> In-Reply-To: <a46e561d-6227-44be-484e-50af813878a2@bsd.com.br> References: <f1578a63-2a90-6bd1-4444-d96c1829e0dc@bsd.com.br> <20170305104832.56d4e358bc968c4e03eca2b2@yahoo.es> <a46e561d-6227-44be-484e-50af813878a2@bsd.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 5 Mar 2017, at 10:09, Otac=C3=ADlio <otacilio.neto@bsd.com.br> = wrote: >=20 > Em 05/03/2017 06:48, Eduardo Morras via freebsd-hackers escreveu: >> On Sat, 4 Mar 2017 23:29:57 -0300 >> Otac=C3=ADlio <otacilio.neto@bsd.com.br> wrote: >>=20 >>> Dears >>>=20 >>> I'm trying to compile a simple hello world program on my RPI3. The >>> program is on a directory mounted using NFS and stored in the amd64 >>> machine. When I compile and try to run the program in the NFS = mounted >>> path it does not work, when I copy the same program to a local dir = it >>> work, and then when I copy the program from the local dir to the NFS >>> dir it works !? !?!?! Someone can, please, explain it? Look at the >>> historic program. >> I assume you crosscompiled it to arm, but .. DId you static linked = it? If not, it gets requiered .so from nfs server and crash, becuase = they are amd64 binary. >>=20 >>=20 >>=20 >=20 > I'm not compiling using the server tools. I'm compiling using the RPI3 = tools inside the RPI3. The server is only exporting the /usr/ports. I = mounted this on PRI3 /usr/ports and I'm compiling using the RPI3 clang. = On this same scenario, when using a BBB this works. I=E2=80=99ve seen this on a ThunderX in the netsurf cluster. It seems to = be getting the check in [1] (CC=E2=80=99d the author of said code). = Building as a static binary doesn=E2=80=99t affect it. I=E2=80=99ve added debugging to & found np->n_mtime and = np->n_vattr.na_mtime can be out by up to a few seconds. Even when the = second is the same, the tv_nsec value are different, however I don=E2=80=99= t know the nfs code well enough to know where these values come from. Andrew [1] http://fxr.watson.org/fxr/source/fs/nfsclient/nfs_clbio.c#L1633=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1E759624-BA9B-4039-8E70-711D7435EB4B>