Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sat, 2017-12-09 at 13:03 -0800, Matt Turner wrote: > On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet > wrote: > > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > > > > > Thanks for the quick reply! > > > > > > I tried the patch on top of master, but

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sat, 2017-12-09 at 13:03 -0800, Matt Turner wrote: > On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet > wrote: > > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > > > > > Thanks for the quick reply! > > > > > > I tried the patch on top of master, but unfortunately the > > > corruption

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet wrote: > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: >> >> Thanks for the quick reply! >> >> I tried the patch on top of master, but unfortunately the corruption >> still occurs. > > You might try replacing in

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, Dec 8, 2017 at 1:16 PM, Eric Dumazet wrote: > On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: >> >> Thanks for the quick reply! >> >> I tried the patch on top of master, but unfortunately the corruption >> still occurs. > > You might try replacing in sbdma_add_rcvbuffer() > > sb_new

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > Thanks for the quick reply! > > I tried the patch on top of master, but unfortunately the corruption > still occurs. You might try replacing in sbdma_add_rcvbuffer() sb_new = netdev_alloc_skb(dev, size); by  sb_new = alloc_skb(size,

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 12:26 -0800, Matt Turner wrote: > > Thanks for the quick reply! > > I tried the patch on top of master, but unfortunately the corruption > still occurs. You might try replacing in sbdma_add_rcvbuffer() sb_new = netdev_alloc_skb(dev, size); by  sb_new = alloc_skb(size,

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, Dec 8, 2017 at 5:52 AM, Eric Dumazet wrote: > On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: >> On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner >> wrote: >> > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner >> > wrote: >>

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, Dec 8, 2017 at 5:52 AM, Eric Dumazet wrote: > On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: >> On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner >> wrote: >> > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner >> > wrote: >> > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner >> > > wrote:

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: > On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner > wrote: > > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner > > wrote: > > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner > > > wrote:

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Fri, 2017-12-08 at 05:42 -0800, Eric Dumazet wrote: > On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner > wrote: > > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner > > wrote: > > > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner > > > wrote: > > > > On a Broadcom BCM91250a MIPS system I can reliably

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner wrote: > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: >> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >>>

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:54 PM, Matt Turner wrote: > On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: >> On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >>> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >>> corruption on the first file read. >>> >>> To demonstrate, I

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >> corruption on the first file read. >> >> To demonstrate, I downloaded five

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Thu, Dec 7, 2017 at 11:00 PM, Matt Turner wrote: > On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: >> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >> corruption on the first file read. >> >> To demonstrate, I downloaded five identical copies of the gcc-5.4.0 >> source

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS > corruption on the first file read. > > To demonstrate, I downloaded five identical copies of the gcc-5.4.0 > source tarball. On the NFS server, they hash to

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner wrote: > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS > corruption on the first file read. > > To demonstrate, I downloaded five identical copies of the gcc-5.4.0 > source tarball. On the NFS server, they hash to the same value: > >

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Mon, Mar 13, 2017 at 09:47:57AM +, James Hogan wrote: > > > > Note that the corruption is different across reboots, both in the size > > of the corruption and the location. I saw 1900~ and 1400~ byte > > sequences corrupted on separate occasions, which don't correspond to > > the system's

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Mon, Mar 13, 2017 at 09:47:57AM +, James Hogan wrote: > > > > Note that the corruption is different across reboots, both in the size > > of the corruption and the location. I saw 1900~ and 1400~ byte > > sequences corrupted on separate occasions, which don't correspond to > > the system's

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Mon, Mar 13, 2017 at 2:47 AM, James Hogan wrote: > On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote: >> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >> corruption on the first file read. >> >> To demonstrate, I downloaded five identical

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Mon, Mar 13, 2017 at 2:47 AM, James Hogan wrote: > On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote: >> On a Broadcom BCM91250a MIPS system I can reliably trigger NFS >> corruption on the first file read. >> >> To demonstrate, I downloaded five identical copies of the gcc-5.4.0 >>

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote: > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS > corruption on the first file read. > > To demonstrate, I downloaded five identical copies of the gcc-5.4.0 > source tarball. On the NFS server, they hash to the same

Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?

On Sun, Mar 12, 2017 at 06:43:47PM -0700, Matt Turner wrote: > On a Broadcom BCM91250a MIPS system I can reliably trigger NFS > corruption on the first file read. > > To demonstrate, I downloaded five identical copies of the gcc-5.4.0 > source tarball. On the NFS server, they hash to the same