From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756011AbcLOT2F (ORCPT ); Thu, 15 Dec 2016 14:28:05 -0500 Received: from mout.gmx.net ([212.227.15.18]:53883 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753187AbcLOT2D (ORCPT ); Thu, 15 Dec 2016 14:28:03 -0500 Subject: Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock To: Pavel Machek References: <1481141138-19466-1-git-send-email-LinoSanfilippo@gmx.de> <1481141138-19466-2-git-send-email-LinoSanfilippo@gmx.de> <20161207231534.GB5889@electric-eye.fr.zoreil.com> <051e3043-8b58-0591-36e3-99e2267f67f4@gmx.de> <20161208231943.GA13102@electric-eye.fr.zoreil.com> <20161209112142.GA22710@amd> <20161211201104.GB20574@amd> Cc: Francois Romieu , bh74.an@samsung.com, ks.giri@samsung.com, vipul.pandya@samsung.com, peppe.cavallaro@st.com, alexandre.torgue@st.com, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@vger.kernel.org From: Lino Sanfilippo Message-ID: Date: Thu, 15 Dec 2016 20:27:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161211201104.GB20574@amd> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qdZMfQvk8U109qCb2mrJheB61XCltdC5Cf02UfOn7dWHKij07Lt VZktlgEiOfZpGM2167tvM1axLbKlcUFo+bDPgR/u4SbzndSSXdEQ6ZxY/6aEvQZG6HncR1G ephddqX+78C4BEOJ6KS7W0nc9pvGQ/TFcuX2NyyyIpT7v3uwrZdZP++CgT2eBXkei60yiMm bCw5gvPwIDunc+ieKXF+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:5xjv0qW9U8I=:oUbsQLomyvbrK4pUaU3eJi shVnubeprAH4qv7bXBtRtXxrTfLi0Zx2aI8HVGGg8niSyIpC5ZeMrUZRzpGljQ2aKNtQJxHAq FD5rYlDz3gpGcYhfd9Jk1GQmBweRGbROBP8KVVQk2dKxLSVNY4wU7zl+yvlhHCDTPWanTGei5 KuN8JzPs5Tg7Z1g1ja+CIY5jIA4XyL6UYp4iC0ozkzrlX1WtIOH2weh8xoFGRPjaC6Wk0/MAT eHlSD8ie76Hz3Km/r4swoau5xPk7SkEqQHD5Ztr9tq9Fcu/WCgAISytP9bSsVYmlHqj2L8ooJ BeF5kBv4oXCmCTJ+ryG1TnR9VAuNC+VncwvbhetBRNOI9/CxFZ+d0Q4afTZXAkg6GzLaprO7P L4JJ/iMz4L0AVOspJENWfRg+nWZr6SFLvf2luOb8VTtTxt/nWH8AIE5pHINEDK1GEh/BHd0P1 AkunJCsNYR7QiTvEELOFZsy7rFQcEVxmUiyUxVERVco/cdecoPHpff3/fCICFFLooAoJpEd8O r4vu+q1I8hBtMaK5sn5xP+2oR93Ju4Z4fQgX4SpMQyVf+vnVJdiJ86f7K1A0TW6L+YkXsjHxa 0YyClNawReNXBcegNYIcCFMlRAiHSQCGfEcYGKRajkL4/0zo6guIML/wju+VaS63DwM7b+31r E+0GxOuHt3iXXM4FpkBac7V27zHE+KXuBZ0jc29tiFyNzVOHjwYYZh5E4bZNpPi1zS/8UriYM c+DtHjxSjZgqF+v0Vyg0GmkH0AmSv4oWL3YCyjdeU3GNZeJJh+1b2+ZG4TXUUgDDH/LgyOgw2 odvc3oZ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavel, sorry for the late reply. On 11.12.2016 21:11, Pavel Machek wrote: > > Do you understand what stmmac_tx_err(priv); is supposed to do? In > particular, if it is called while the driver is working ok -- should > the driver survive that? As far as I understood it is supposed to fixup an errorneous tx path, e.g. a missing tx completion for transmitted frames. Some drivers do this by restarting only the HW parts responsible for tx, some others by restarting the complete hardware. But IMO it should also be ok to be called if the HW is still working fine. > Because it does not currently, and I don't know how to test that > code. Unplugging the cable does not provoke that. > > I tried > > } else if (unlikely(status == tx_hard_error)) > stmmac_tx_err(priv); > + > + { > + static int i; > + i++; > + if (i==1000) { > + i = 0; > + printk("Simulated error\n"); > + stmmac_tx_err(priv); > + } > + } > } > Ok, there is this race that Francois mentioned so it is not surprising that the driver does not survive the call of stmmac_tx_err() as it is called now. Thats why I suggested to do a proper shutdown and restart of the tx path to avoid the race. Regards, Lino