| Message ID | 8214704e-45cf-d689-f233-d49097b996ac@samsung.com |
|---|---|
| State | RFC |
| Delegated to: | Joe Hershberger |
| Headers | show |
On Mon, Apr 10, 2017 at 6:24 PM, Joe Hershberger <joe.hershberger@ni.com> wrote: > Hi Jaehoon, > > On Mon, Apr 10, 2017 at 5:23 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >> Dear Joe, >> >> I have a question about nfs. >> I don't have a knowledge for NFS..So i don't know this is right or not.. >> >> When i have tested the latest u-boot(v2017.03), nfs doesn't work fine with Odroid-xu3. > > How does it fail? Did you print out what the value of "len" is in the > case where it was failing? How does it compare to the static size of > the struct? > >> My question is a below thing...In net/nfs.c, nfs_read_reply() function is called the memcpy(). >> it should be copied the sizeof(rpc_pkt.u.reply))...is it really right? > > It may be copying too much, but I wouldn't expect that to be an issue. > > If it is not copying enough, then maybe NFS_READ_SIZE is not set > appropriately? Or maybe there is an issue with how the server decides > what read size to use? > >> diff --git a/net/nfs.c b/net/nfs.c >> index 83ed0a7..09556c7 100644 >> --- a/net/nfs.c >> +++ b/net/nfs.c >> @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len) >> >> debug("%s\n", __func__); >> >> memcpy(&rpc_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply)); >> >> >> When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine. >> >> Maybe i'm wrong..so i asked this to you... > > Please do some debugging with the Odroid and report values. > > Thanks, > -Joe > >> Best Regards, >> Jaehoon Chung Not sure that this email ever went out... I've been having trouble with sent emails in the last few months. :/ -Joe
Hi Joe, On 05/31/2017 05:37 AM, Joe Hershberger wrote: > On Mon, Apr 10, 2017 at 6:24 PM, Joe Hershberger <joe.hershberger@ni.com> wrote: >> Hi Jaehoon, >> >> On Mon, Apr 10, 2017 at 5:23 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote: >>> Dear Joe, >>> >>> I have a question about nfs. >>> I don't have a knowledge for NFS..So i don't know this is right or not.. >>> >>> When i have tested the latest u-boot(v2017.03), nfs doesn't work fine with Odroid-xu3. >> >> How does it fail? Did you print out what the value of "len" is in the >> case where it was failing? How does it compare to the static size of >> the struct? I will share the information when it's failed. >> >>> My question is a below thing...In net/nfs.c, nfs_read_reply() function is called the memcpy(). >>> it should be copied the sizeof(rpc_pkt.u.reply))...is it really right? >> >> It may be copying too much, but I wouldn't expect that to be an issue. >> >> If it is not copying enough, then maybe NFS_READ_SIZE is not set >> appropriately? Or maybe there is an issue with how the server decides >> what read size to use? i didn't check in more detail..so i will debug more about what is main problem.. >> >>> diff --git a/net/nfs.c b/net/nfs.c >>> index 83ed0a7..09556c7 100644 >>> --- a/net/nfs.c >>> +++ b/net/nfs.c >>> @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len) >>> >>> debug("%s\n", __func__); >>> >>> memcpy(&rpc_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply)); >>> >>> >>> When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine. >>> >>> Maybe i'm wrong..so i asked this to you... >> >> Please do some debugging with the Odroid and report values. Sure, I will do. >> >> Thanks, >> -Joe >> >>> Best Regards, >>> Jaehoon Chung > > Not sure that this email ever went out... I've been having trouble > with sent emails in the last few months. :/ > > -Joe > > >
diff --git a/net/nfs.c b/net/nfs.c index 83ed0a7..09556c7 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -660,7 +660,8 @@ static int nfs_read_reply(uchar *pkt, unsigned len) debug("%s\n", __func__); memcpy(&rpc_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply)); When i changed from "sizeof(rpc_pkt.u.reply)" to "len", it was working fine.