On 8/4/15 1:13 PM, Jeff Rizzo wrote:
On 8/4/15 4:20 AM, Robert Swindells wrote:
David Holland wrote:
Does that size vary with the NFS block size?
Yep. Reducing blocksize to 8192 makes it barf on 8192+ byte files.
Also is it using UDP or TCP ?
TCP, but I just confirmed UDP has the problem too.
The symptoms make me think of scrambled mbufs, if anything...
My guess is that the panics that wiz and I saw in the checksum code
on amd64 were also due to scrambled mbufs.
My cubietruck seems fine using awge(4), I have built a fair number of
packages over NFS recently.
Robert Swindells
Looks like awge(4) is seeing output errors:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs
Colls
awge0 1500 <Link> 00:1e:06:c3:49:c1 189582 0 134261
222 0
Not sure of what variety, though. The oerrs go up when reading a
large file (90M) which checksums properly, but DON'T go up when
writing/reading an 8k file which gets corrupted.
+j
I finally got around to sticking a USB interface (urtwn0) in and testing
NFS over that... it was PAINFULLY SLOW - took well over a minute to copy
a 4MB test file. But, the test file copied with no corruption!
This would seem to indicate a problem with the particular interface
(awge0), perhaps specific to the odroid-c1, as opposed to some l2 cache
controller issue, which is kind of where I was leaning before. However,
my banana pi has awge0 as well, but does not exhibit this corruption.
Any suggestions what to try/test next gratefully accepted - I would
really love to get nfs working on this board.
+j
