linux-mips
[Top] [All Lists]

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

To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, linux-nfs@vger.kernel.org, Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Hannes Frederic Sowa <hannes@stressinduktion.org>, "Peter Zijlstra (Intel)" <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@kernel.org>
Subject: Re: NFS corruption, fixed by echo 1 > /proc/sys/vm/drop_caches -- next debugging steps?
From: Matt Turner <mattst88@gmail.com>
Date: Thu, 7 Dec 2017 23:00:52 -0800
Cc: Manuel Lauss <manuel.lauss@gmail.com>, LKML <linux-kernel@vger.kernel.org>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oESnI2wP4cXMECuKJduPTGXVujngMRd87B+g0mU2wCE=; b=VpfP/Ke7DPsvV8dQtrJ1hgbdf8i48Yaeu/ztnbnQfaUKz8KgUucOqz2+XYFAxnWrdC btM+s8kuF8CwF9DgNsKY4ZYiK/bzy+pqMvuCrSEroy/nW2RbDrNWzh3l7SOShH5NGW1z FwADwmJ4o3QjQHmL3QOY2OugSDbOYyTyWXLLYXReRZX23wXV6DRq9LRtec8M8PIqBTko Id+KYr6OOkx/RJUj0tzA7wOFDafmjg0Us9CEjfy7emx2uuKkhY80Ip97ugqT2UiK9CQj DEzN1oLc6cWZ1QUYfdmXBUUM+MzHqBRQdJy7CPzJhFtMvNDj6A7cWM3MZeK8vH8GUm3Z rJ8Q==
In-reply-to: <CAEdQ38HcOgAT6wJWWKY3P0hzYwkBGSQkRSQ2a=eaGmD6c6rwXA@mail.gmail.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <CAEdQ38HcOgAT6wJWWKY3P0hzYwkBGSQkRSQ2a=eaGmD6c6rwXA@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
On Sun, Mar 12, 2017 at 6:43 PM, Matt Turner <mattst88@gmail.com> 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:
>
> server distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> On the MIPS system (the NFS client):
>
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2.2
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 35346975989954df8a8db2b034da610d  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> The first file read will contain some corruption, and it is persistent 
> until...
>
> bcm91250a-le distfiles # echo 1 > /proc/sys/vm/drop_caches
> bcm91250a-le distfiles # md5sum gcc-5.4.0.tar.bz2*
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.1
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.2
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.3
> 4c626ac2a83ef30dfb9260e6f59c2b30  gcc-5.4.0.tar.bz2.4
>
> the caches are dropped, at which point it reads back properly.
>
> 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 16kB page size.
>
> I've tested kernels from v3.19 to 4.11-rc1+ (master branch from
> today). All exhibit this behavior with differing frequencies. Earlier
> kernels seem to reproduce the issue less often, while more recent
> kernels reliably exhibit the problem every boot.
>
> How can I further debug this?

I think I was wrong about the statement about kernels v3.19 to
4.11-rc1+. I found out I couldn't reproduce with 4.7-rc1 and then
bisected to 4cd13c21b207e80ddb1144c576500098f2d5f882 ("softirq: Let
ksoftirqd do its job"). Still reproduces with current tip of Linus'
tree.

Any ideas? The board's ethernet is an uncommon device supported by
CONFIG_SB1250_MAC. Something about the ethernet driver maybe?

<Prev in Thread] Current Thread [Next in Thread>