From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B6A1C433E7 for ; Tue, 20 Oct 2020 06:16:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 05834223BF for ; Tue, 20 Oct 2020 06:16:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392045AbgJTGQo (ORCPT ); Tue, 20 Oct 2020 02:16:44 -0400 Received: from kernel.crashing.org ([76.164.61.194]:42864 "EHLO kernel.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403760AbgJTGQk (ORCPT ); Tue, 20 Oct 2020 02:16:40 -0400 Received: from localhost (gate.crashing.org [63.228.1.57]) (authenticated bits=0) by kernel.crashing.org (8.14.7/8.14.7) with ESMTP id 09K6FhPZ029406 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Oct 2020 01:15:56 -0500 Message-ID: <3ebaa814fe21eb7b4b25a2c9455a34434e0207d6.camel@kernel.crashing.org> Subject: Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue From: Benjamin Herrenschmidt To: Jakub Kicinski Cc: Joel Stanley , Dylan Hung , "David S . Miller" , netdev@vger.kernel.org, Linux Kernel Mailing List , Po-Yu Chuang , linux-aspeed , OpenBMC Maillist , BMC-SW , Arnd Bergmann , linux-arch@vger.kernel.org Date: Tue, 20 Oct 2020 17:15:42 +1100 In-Reply-To: <20201019195723.41a5591f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201019073908.32262-1-dylan_hung@aspeedtech.com> <20201019120040.3152ea0b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1a02e57b6b7d425a19dc59f84091c38ca4edcf47.camel@kernel.crashing.org> <20201019195723.41a5591f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2020-10-19 at 19:57 -0700, Jakub Kicinski wrote: > > I suspect the problem is that the HW (and yes this would be a HW bug) > > doesn't order the CPU -> memory and the CPU -> MMIO path. > > > > What I think happens is that the store to txde0 is potentially still in > > a buffer somewhere on its way to memory, gets bypassed by the store to > > MMIO, causing the MAC to try to read the descriptor, and getting the > > "old" data from memory. > > I see, but in general this sort of a problem should be resolved by > adding an appropriate memory barrier. And in fact such barrier should > (these days) be implied by a writel (I'm not 100% clear on why this > driver uses iowrite, and if it matters). No, a barrier won't solve this I think. This is a coherency problem at the fabric/interconnect level. I has to do with the way they implemented the DMA path from memory to the ethernet controller using a different "port" of the memory controller than the one used by the CPU, separately from the MMIO path, with no proper ordering between those busses. Old school design .... and broken. By doing a read back, they probably force the previous write to memory to get past the point where it will be visible to a subsequent DMA read by the ethernet controller. > > It's ... fishy, but that isn't the first time an Aspeed chip has that > > type of bug (there's a similar one in the USB device controler iirc). Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF878C433E7 for ; Tue, 20 Oct 2020 06:18:23 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E0A3622282 for ; Tue, 20 Oct 2020 06:18:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E0A3622282 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CFk2h2dXwzDqX3 for ; Tue, 20 Oct 2020 17:18:20 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=permerror (SPF Permanent Error: Unknown mechanism found: ip:192.40.192.88/32) smtp.mailfrom=kernel.crashing.org (client-ip=76.164.61.194; helo=kernel.crashing.org; envelope-from=benh@kernel.crashing.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Received: from kernel.crashing.org (kernel.crashing.org [76.164.61.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CFk0l3cNJzDqXQ; Tue, 20 Oct 2020 17:16:37 +1100 (AEDT) Received: from localhost (gate.crashing.org [63.228.1.57]) (authenticated bits=0) by kernel.crashing.org (8.14.7/8.14.7) with ESMTP id 09K6FhPZ029406 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 20 Oct 2020 01:15:56 -0500 Message-ID: <3ebaa814fe21eb7b4b25a2c9455a34434e0207d6.camel@kernel.crashing.org> Subject: Re: [PATCH] net: ftgmac100: Fix missing TX-poll issue From: Benjamin Herrenschmidt To: Jakub Kicinski Date: Tue, 20 Oct 2020 17:15:42 +1100 In-Reply-To: <20201019195723.41a5591f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> References: <20201019073908.32262-1-dylan_hung@aspeedtech.com> <20201019120040.3152ea0b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <1a02e57b6b7d425a19dc59f84091c38ca4edcf47.camel@kernel.crashing.org> <20201019195723.41a5591f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, BMC-SW , linux-aspeed , Po-Yu Chuang , netdev@vger.kernel.org, OpenBMC Maillist , Linux Kernel Mailing List , Arnd Bergmann , Dylan Hung , "David S . Miller" Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Mon, 2020-10-19 at 19:57 -0700, Jakub Kicinski wrote: > > I suspect the problem is that the HW (and yes this would be a HW bug) > > doesn't order the CPU -> memory and the CPU -> MMIO path. > > > > What I think happens is that the store to txde0 is potentially still in > > a buffer somewhere on its way to memory, gets bypassed by the store to > > MMIO, causing the MAC to try to read the descriptor, and getting the > > "old" data from memory. > > I see, but in general this sort of a problem should be resolved by > adding an appropriate memory barrier. And in fact such barrier should > (these days) be implied by a writel (I'm not 100% clear on why this > driver uses iowrite, and if it matters). No, a barrier won't solve this I think. This is a coherency problem at the fabric/interconnect level. I has to do with the way they implemented the DMA path from memory to the ethernet controller using a different "port" of the memory controller than the one used by the CPU, separately from the MMIO path, with no proper ordering between those busses. Old school design .... and broken. By doing a read back, they probably force the previous write to memory to get past the point where it will be visible to a subsequent DMA read by the ethernet controller. > > It's ... fishy, but that isn't the first time an Aspeed chip has that > > type of bug (there's a similar one in the USB device controler iirc). Cheers, Ben.