Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755985AbcLOVdy (ORCPT ); Thu, 15 Dec 2016 16:33:54 -0500 Received: from mout.gmx.net ([212.227.17.20]:62291 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754530AbcLOVdo (ORCPT ); Thu, 15 Dec 2016 16:33:44 -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> <20161215210324.GA13878@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 22:32:59 +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: <20161215210324.GA13878@amd> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DmXXMDqYycG6hmJ/sv4Mh5iMU30eih9jrO+gQKTy5PPVCRpRj+S BH988RbRbEBvnz6xTNsR4LSqKYjo/hUNP6HCKxUCmdz7sc+y+CLN1Lkvh+KKWjot0d7Sj92 o5Yo1wYks8VW3O2W16XPGPxASSqSvSH/vFq4Qg2wksWm7nTDzjRwgMU6yXH8Rv+FFISpqXp 8L2rirRs0DpXBQ4tVsIBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:c5Fa5/aj9qQ=:eoxHxb8xX++HkhAyziWR7b cthiYmMnK4OSq2Ot3pbQAdd0aqg4PwfQ8fL2FVsU507fFTf+oEXib21LfDFeCYMT8BLiDwZdW XRXM3LkQArIuHF/42TvrBfaYMu2d6QCjGeT+ygRmJcT9jP6yxK8TD8nBOakRevh84j5M+8a8q GbyQI2TzHlEJipK89pBoWwLMgkABWNR/C/yupkRvvo8+ckT6ot80ZztwusGsL0NR8vgi3cJh6 H62P2gs88mGIO3goeIW1u4TzZsqijd4I5X4MnWBJb7Gjt/H/iY04PGFtpJmvGwt9RRA6xlBY4 Ef92XV1vXhoPKzjerkhsna9wLf6wpqyT+O12U7gqKrTlsvsjIcFY1RnTGmaD4xVelaTKP+pir SYwlGgQB/ITB5Kynb4nGS1mh8OO7R1myU3CGEv+DSW8EdvBs3I6ibcKhzQ1iF5HlL11j93VUp xsLcrpXZ+jBEKJIpZGz46rlHOTYXUtAb1fMhRWjZnae71GVdSLLXkjJVvVyO+f2MmB9cdnaYt HHzCq7Na9eMIVU89ITQmwseNMDq5sHHAtdWZDIf/LhQN9/YMs3i83hneJ/AumqplngWQqPjSG 3YMRHOfNSeYJXckwU7nlHNJtzIev2DiZ6R+7jTvoQOcxD22JoOX9xXU7yIQm3ilJxVyibG/Mu +W/UFAFPy6zCmNCz2fC/rVemHi3O24YlBle31PElJN8vuw7a/MAOpbmvxjJAd5PfX6dH0Mjz/ 19+SxbQYWkrHNRwd0WuuVngMN9w2QEw1pgU/8xj2py5y5zYx0f8Gm9N6Fa67kc7hWxIbiqNSI UogINOB Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 523 Lines: 14 On 15.12.2016 22:03, Pavel Machek wrote: > > I actually did experiment with adding locking there, too, and no, no > luck. It seems stmmac_tx_err() is more broken than just locking. > Ah ok. Then maybe priv->hw->dma->stop_tx() does not do the job correctly (stop the tx path properly) and the HW is still active on the tx path while the tx buffers are freed. OTOH stmmac_release() also stops the phy before the tx (and rx) paths are stopped. Did you try to stop the phy fist in stmmac_tx_err_work(), too? Regards, Lino